Thread: RE: [Cxxgui-devel] RE: C++ GUI library
Brought to you by:
davidturner
Menu
▾
▴
cxxgui-devel
|
From: David T. <Da...@fi...> - 2004-03-10 05:58:48
|
Hi Daniel > I better tell you what I've been up to then. As I mentioned=20 > on the boost > list, I've been writing some jamfiles for boost build. I've got it > working on linux with GTK, and almost working on windows. Great. I've added you to the developer's list on the project, so you should be able to commit your changes. > At the moment the code doesn't work on cygwin or visual c++ 6. Which > probably isn't that surprising. I don't know if its worth=20 > bothering with > visual c++ 6, since it looks like many of the boost libraries=20 > are going > to give up on it over the next year or two. Hmm. It would be nice to have it working... unfortunately I don't have VC6 anymore. If you could send me an error output, maybe I can fix it. I suspect that the problem will be the factory. It should be quite easy to write it in a compatible manner. I'll test with cygwin and mingw this end. Regards David Turner |
|
From: Daniel J. <dan...@em...> - 2004-03-10 20:12:56
|
On Wed, 2004-03-10 at 05:33, David Turner wrote: > Great. I've added you to the developer's list on the project, so you > should be able to commit your changes. Ok, it's checked in. They still need quite a bit of work. There's stuff in the Jamfile for test which should be defined in the library jamfile. But it does work for GTK. > Hmm. It would be nice to have it working... unfortunately I don't have > VC6 anymore. If you could send me an error output, maybe I can fix it. > I suspect that the problem will be the factory. It should be quite easy > to write it in a compatible manner. > > I'll test with cygwin and mingw this end. I've been trying it with cygwin as well. Anyway, here's a list of problems. Most of them I can fix, but I just want to check what the right way is. 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. - main.cpp calls _beginthreadex(), which isn't on cygwin. I have no idea what the cygwin equivalent of that is. 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. 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. 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. 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. Daniel |
|
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 |
|
From: David T. <dkt...@te...> - 2004-03-11 20:19:49
|
Hi Daniel On Wed, 2004-03-10 at 21:39, Daniel James wrote: > Ok, it's checked in. They still need quite a bit of work. There's stuff > in the Jamfile for test which should be defined in the library jamfile. > But it does work for GTK. I think you forgot to "cvs add" the build/ subdirectory? Regards David Turner |
|
From: Daniel J. <dan...@em...> - 2004-03-12 15:10:32
|
David Turner wrote: > I think you forgot to "cvs add" the build/ subdirectory? It looks like it's in there. Did you use the -d flag for cvs? ie. cvs update -d. I always forget to do that. Daniel |
|
From: David T. <dkt...@te...> - 2004-03-12 16:04:41
|
On Fri, 2004-03-12 at 16:21, Daniel James wrote: > David Turner wrote: > > I think you forgot to "cvs add" the build/ subdirectory? > > It looks like it's in there. Did you use the -d flag for cvs? ie. cvs > update -d. I always forget to do that. Oops, my apologies. Missing .cvsrc *blush*. Regards David Turner |
|
From: Daniel J. <dan...@em...> - 2004-03-12 15:10:41
|
David Turner wrote: > #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? OK, I've done it this way, but I'm not sure about it. Every compiler that's available to me (Visual C++ 6, Borland, mingw, cygwin, Digital Mars) supports alloca, _alloca or both, so I don't think TEMP_FREE is really needed. I'm worried about exception safety when using it, it seems like it could easily lead to leaks. > CreateThreadEx() is appropriate, I think. > [snip] > I'll look into this. Thanks, I've only ever used boost for multithreading, so I wouldn't know where to start here. Daniel |
|
From: David T. <dkt...@te...> - 2004-03-12 16:11:15
|
On Fri, 2004-03-12 at 16:21, Daniel James wrote: > > OK, I've done it this way, but I'm not sure about it. Every compiler that's > available to me (Visual C++ 6, Borland, mingw, cygwin, Digital Mars) > supports alloca, _alloca or both, so I don't think TEMP_FREE is really > needed. I'm worried about exception safety when using it, it seems like it > could easily lead to leaks. Thanks, Daniel. I don't think exceptions are a worry (as long as those macros are used only as intended ;-)). I should be ready to commit the new list widget sometime tonight. After that I'll get it to run on Cygwin. Regards David Turner |
Thanks for helping keep SourceForge clean.
X