RE: [Cxxgui-devel] RE: C++ GUI library
Brought to you by:
davidturner
From: David T. <dkt...@te...> - 2004-03-11 18:18:56
|
On Wed, 2004-03-10 at 21:39, Daniel James wrote: > Cygwin Problems: > > - The windows code uses _alloca, but cygwin doesn't have this, it has > alloca instead. I guess that the best thing to do is a define a macro > which calls the right one, say CXXGUI_ALLOCA or something similar. I > think this could be defined in win32.hpp, because that's included by all > the windows implementation files, or would you prefer a separate header? > Alternatively we could use boost::scoped_array. Yes, _alloca is MSVC-specific. This should be quite easy to work around, and the win32 header is the place to do it. In fact, I think it should really be done with a pair of macros: #ifdef MSC_VER #include <malloc.h> #define TEMP_ALLOC(size) _alloca(size) #define TEMP_FREE(ptr) #elseif defined(CYGWIN) #define TEMP_ALLOC(size) alloca(size) #define TEMP_FREE(ptr) #else #define TEMP_ALLOC(size) malloc(size) #define TEMP_FREE(ptr) free(ptr) #endif Can you fix this, please? > > - main.cpp calls _beginthreadex(), which isn't on cygwin. I have no idea > what the cygwin equivalent of that is. CreateThreadEx() is appropriate, I think. The reason I don't use a boost::thread here is because boost::thread waits for the thread to commence execution. Threads started in DllMain don't actually begin running until the call to DllMain returns, which means that boost::thread deadlocks if it's used here. _beginthreadex() is comparable to CreateThreadEx, except that it also initializes thread-local storage and mutexes for various standard library variables. I'll look into this. > > Visual C++ 6 problems: > > - SetWindowLongPtr, GetWindowLongPtr and LONG_PTR aren't available, you > need to use SetWindowLong, GetWindowLong and LONG. I guess that we > should either define the missing functions for Visual C++ 6, or provide a > wrapper function which call the appropriate version. I realise that we > want to use the newer functions when they're available. That's a tricky one. On the other hand, I doubt Visual C++ 6 is going to be used much on 64 bit architectures, so it should be okay to #define this problem away. > There are some other problems, but I think I can fix them quite easily, > I'll have a go when I get the chance and post patches to the list, so > that you can say if they're okay. I also checked in a quick change to > util.hpp, so that is uses BOOST_DEDUCED_TYPENAME. It seemed trivial > enough that I didn't need to check first. Indeed :-). > Even if all these problems are fixed, the build system still won't work > on windows, because it doesn't create the dll properly. I think that may > take me a little while to get working. I managed to successfully build > the cygwin version, by making it single threaded, but it crashed when I > clicked on the button to open the new window. I think it died at the > message loop. Hmm. What were the symptoms? In theory, this library should be able to work on single-threaded architectures :-). > I'm also not sure how to link the application so that it calls 'main' > instead of 'winmain' but still acts like a GUI app. I think the GTK folks solved this one by writing a WinMain function that did the globbing and then called main(). Windows certainly has a function to do the globbing in there somewhere, but whether or not it has an API for it is a totally different question. For the moment, I'm not too concerned about this problem, but I agree that it would be nice to make it go away. Regards David Turner |