I updated from 1.35 to 1.38 when the conflicts started. My MFC application wouldn't start, it would throw an exception. I pinned down the problem to the hook that boost thread library is using which is located in tss_pe.cpp: extern "C" { extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD, LPVOID)=&dll_callback; } What I did is comment this declaration and rebuild the library and now my application seems to be running normally. My question is can boost thread library run properly without this hook? If not, what other solution do you suggest. Thanks, Igor. -- View this message in context: http://www.nabble.com/Boost-thread-conflicts-with-MFC-tp22946168p22946168.ht... Sent from the Boost - Users mailing list archive at Nabble.com.
Igor MI <kostadinovigor@gmail.com> writes:
I updated from 1.35 to 1.38 when the conflicts started. My MFC application wouldn't start, it would throw an exception. I pinned down the problem to the hook that boost thread library is using which is located in tss_pe.cpp:
extern "C" { extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD, LPVOID)=&dll_callback; }
What I did is comment this declaration and rebuild the library and now my application seems to be running normally. My question is can boost thread library run properly without this hook? If not, what other solution do you suggest.
This hook is necessary when using static-linked boost.thread in a DLL, in order to ensure that the thread-specific data allocated for each thread is cleaned up. I have been sent a patch to handle this case, and will try and integrate it into boost.thread sometime soon. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Thread documentation contains some dire warnings about using the package with MFC. Will this patch permit these warnings to be ignored and use the thread package with MFC? Robert Ramey Anthony Williams wrote:
Igor MI <kostadinovigor@gmail.com> writes:
I updated from 1.35 to 1.38 when the conflicts started. My MFC application wouldn't start, it would throw an exception. I pinned down the problem to the hook that boost thread library is using which is located in tss_pe.cpp:
extern "C" { extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD, LPVOID)=&dll_callback; }
What I did is comment this declaration and rebuild the library and now my application seems to be running normally. My question is can boost thread library run properly without this hook? If not, what other solution do you suggest.
This hook is necessary when using static-linked boost.thread in a DLL, in order to ensure that the thread-specific data allocated for each thread is cleaned up.
I have been sent a patch to handle this case, and will try and integrate it into boost.thread sometime soon.
Anthony
"Robert Ramey" <ramey@rrsd.com> writes:
Thread documentation contains some dire warnings about using the package with MFC. Will this patch permit these warnings to be ignored and use the thread package with MFC?
I'm not sure which warnings you're referring to, but if I can apply the patch successfully in a way that works with and without MFC then yes, the thread library will be usable alongside MFC. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Is it safe to comment it out? I mean I know I will lose some memory resources and thats fine by me, are there any other side effects of commenting this hook? Anthony Williams-4 wrote:
Igor MI <kostadinovigor@gmail.com> writes:
I updated from 1.35 to 1.38 when the conflicts started. My MFC application wouldn't start, it would throw an exception. I pinned down the problem to the hook that boost thread library is using which is located in tss_pe.cpp:
extern "C" { extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD, LPVOID)=&dll_callback; }
What I did is comment this declaration and rebuild the library and now my application seems to be running normally. My question is can boost thread library run properly without this hook? If not, what other solution do you suggest.
This hook is necessary when using static-linked boost.thread in a DLL, in order to ensure that the thread-specific data allocated for each thread is cleaned up.
I have been sent a patch to handle this case, and will try and integrate it into boost.thread sometime soon.
Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- View this message in context: http://www.nabble.com/Boost-thread-conflicts-with-MFC-tp22946168p22966177.ht... Sent from the Boost - Users mailing list archive at Nabble.com.
Igor MI <kostadinovigor@gmail.com> writes:
Is it safe to comment it out? I mean I know I will lose some memory resources and thats fine by me, are there any other side effects of commenting this hook?
For threads started with boost::thread then there should be no side effects. The "leak" affects threads not started with boost::thread, such as the main thread. Any use of boost::this_thread::get_id() from such a thread will allocate some memory for the ID, which won't be freed until app exit. The big issue is with boost::thread_specific_ptr --- any non-NULL pointers normally have their object destroyed on thread exit, but this won't happen for non-boost threads if the exit handler is not called. You can call it manually --- the function to call is on_thread_exit() from boost/thread/detail/tss_hooks.hpp Anthony -- Anthony Williams Author of C++ Concurrency in Action | http://www.manning.com/williams Custom Software Development | http://www.justsoftwaresolutions.co.uk Just Software Solutions Ltd, Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK
I would like to know when this patch is made available. I am having the same issue and commenting out that line fixed my problems as well. Will you reply to this when it is available? Anthony Williams-4 wrote:
I have been sent a patch to handle this case, and will try and integrate it into boost.thread sometime soon.
-- View this message in context: http://www.nabble.com/Boost-thread-conflicts-with-MFC-tp22946168p23024393.ht... Sent from the Boost - Users mailing list archive at Nabble.com.
tinkertom <tinkertom88@gmail.com> writes:
I would like to know when this patch is made available. I am having the same issue and commenting out that line fixed my problems as well. Will you reply to this when it is available?
Yes. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources.
aaaaa .... what do you use instead for development of a C++ windows GUI program? Robert Ramey peter_foelsche@agilent.com wrote:
It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources.
On Thu, Apr 9, 2009 at 12:16 PM, Robert Ramey <ramey@rrsd.com> wrote:
peter_foelsche@agilent.com wrote:
It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources.
aaaaa .... what do you use instead for development of a C++ windows GUI program?
I've heard that even Microsoft doesn't use MFC :) I'm not a C++ GUI guy but I'd rather use a third-party lib like Qt or do WIN32 directly. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
I've heard that even Microsoft doesn't use MFC :)
What do they use? -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean.
On Apr 11, 2009, at 5:20 PM, Ray Burkholder wrote:
I've heard that even Microsoft doesn't use MFC :)
What do they use?
Well...currently they more or less shift over to more WPF (Windows Presentation Foundation) for their *big* applications such as Visual Studio. Nonetheless, as already indicated before in this thread....MFC is far from being dead. It got left aside for a couple of years but Microsoft did overhaul it quite substantially not that long ago. Ciao, Andreas
Andreas Masur wrote:
On Apr 11, 2009, at 5:20 PM, Ray Burkholder wrote:
I've heard that even Microsoft doesn't use MFC :)
What do they use?
Well...currently they more or less shift over to more WPF (Windows Presentation Foundation) for their *big* applications such as Visual Studio. Nonetheless, as already indicated before in this thread....MFC is far from being dead. It got left aside for a couple of years but Microsoft did overhaul it quite substantially not that long ago.
Ciao, Andreas
So far to my knowledge only the text editor in VS2010 is implemented using WPF, and probably a lot of other newer features but the majority is still MFC and COM
On Apr 11, 2009, at 9:32 PM, Raindog wrote:
Andreas Masur wrote:
[...] Well...currently they more or less shift over to more WPF (Windows Presentation Foundation) for their *big* applications such as Visual Studio. Nonetheless, as already indicated before in this thread....MFC is far from being dead. It got left aside for a couple of years but Microsoft did overhaul it quite substantially not that long ago.
Ciao, Andreas
So far to my knowledge only the text editor in VS2010 is implemented using WPF, and probably a lot of other newer features but the majority is still MFC and COM
Yes...currently they only annunced the rewrite of the shell in Visual Studio 2010. But I actually expect more to come over time....certainly they won't turn one of their flagship applications completely over right away. Anyway....I fear that this thread is already driven far beyond its original topic....thus...I actually should refrain from pushing it further.... ;) Ciao, Andreas
last time I developed a GUI application for windows (in 1998), I was using C++ and Win32. We tried MFC and it just did not do it. I remember sick solutions for sick problems in MFC, like sending messages to be called back again later. I simply wrote some C++ wrappers for win32 calls. And I joined these wrappers into base class and member class relationships. The resulting code was very clear, short and maintainable. It contained an activex control container (written in C++) -- not using ATL. I'm amazed that there are still C++ programmers, which don't know about how to wrap a fallible Win32 resource into a C++ class and how to chain such classes into base and member class relationships. I'm amazed that there still seem to be C++ programmers, which don't know how to abort the construction of an object. -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Thursday, April 09, 2009 12:17 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Boost thread conflicts with MFC aaaaa .... what do you use instead for development of a C++ windows GUI program? Robert Ramey peter_foelsche@agilent.com wrote:
It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Well, I guess I'm just an amazing guy. Actually, I'm not all that happy with MFC. But whenver I consider something another alternative, I find them lacking. MFC is a huge body of code which is (mostly) well documented. I typically need and application to support some other project. Recent examples have been a GUI interface to and embedded system. My customers expect this "tail end" application to be doable in say two weeks or so. And they want it to "look like" a "standard" windows app including dockable tool bars, menus, email and web connectivity, support for things like file drag and drop. etc. The only thing I see that can do this besides MFC is Visual Basic. I haven't looked at C#. But those have even bigger downsides. As I said before, I have a lot of complaints about it, but I don't seen anything available that is nearly as comprehensive for windows application development. Robert Ramey peter_foelsche@agilent.com wrote:
last time I developed a GUI application for windows (in 1998), I was using C++ and Win32.
That might explain it.
We tried MFC and it just did not do it. I remember sick solutions for sick problems in MFC, like sending messages to be called back again later.
I simply wrote some C++ wrappers for win32 calls. And I joined these wrappers into base class and member class relationships. The resulting code was very clear, short and maintainable. It contained an activex control container (written in C++) -- not using ATL.
I'm amazed that there are still C++ programmers, which don't know about how to wrap a fallible Win32 resource into a C++ class and how to chain such classes into base and member class relationships.
I'm amazed that there still seem to be C++ programmers, which don't know how to abort the construction of an object.
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Thursday, April 09, 2009 12:17 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Boost thread conflicts with MFC
aaaaa .... what do you use instead for development of a C++ windows GUI program?
Robert Ramey
peter_foelsche@agilent.com wrote:
It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Thu, Apr 9, 2009 at 4:56 PM, Robert Ramey <ramey@rrsd.com> wrote:
Actually, I'm not all that happy with MFC. But whenver I consider something another alternative, I find them lacking. MFC is a huge body of code which is (mostly) well documented. I typically need and application to support some other project. Recent examples have been a GUI interface to and embedded system. My customers expect this "tail end" application to be doable in say two weeks or so. And they want it to "look like" a "standard" windows app including dockable tool bars, menus, email and web connectivity, support for things like file drag and drop. etc.
The only thing I see that can do this besides MFC is Visual Basic. I haven't looked at C#. But those have even bigger downsides.
We mostly use C# and ATL for C++. Have you considered ATL? For our cross-platform apps we use QT, GTK and wxWidgets. Sometimes we just use MainWin which has a port of most of the Win32 library. --Michael Fawcett
----------------------------------------
To: boost-users@lists.boost.org From: Date: Thu, 9 Apr 2009 12:56:20 -0800 Subject: Re: [Boost-users] Boost thread conflicts with MFC
Well, I guess I'm just an amazing guy.
Actually, I'm not all that happy with MFC. But whenver I consider something another alternative, I find them lacking. MFC is a huge body of code which is (mostly) well documented. I typically need and application to support some other project. Recent examples have been a GUI interface to and embedded system. My customers expect this "tail end" application to be doable in say two weeks or so. And they want it to "look like" a "standard" windows app including dockable tool bars, menus, email and web connectivity, support for things like file drag and drop. etc.
Have you considered java for the gui? You can get platform-look-and-feel etc but if your customers absolutely need it to look like Windoze, well... I wouldn't rec it for performance but if you need a gui it is safe and has a lot stuff and has a native interface. It is also a bit more portable than MFC LOL. And, I have to admit I'm still ticked off that the utiliy app that came with my wireless card has to be killed or, even while minimized, it uses up all the GDI objects in a few hours and crashes my machine. If you need to include some production code as an "Afterthought" java avoids really bad things like memory leaks etc...
The only thing I see that can do this besides MFC is Visual Basic. I haven't looked at C#. But those have even bigger downsides.
_________________________________________________________________ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_042009
Mike Marchywka wrote:
Have you considered java for the gui? You can get platform-look-and-feel etc but if your customers absolutely need it to look like Windoze, well... I wouldn't rec it for performance but if you need a gui it is safe and has a lot stuff and has a native interface. It is also a bit more portable than MFC LOL.
I was always turned off by java. My perception was that as an interpreted language it was going to be slower than C++. Why learn yet another language just to go slower. The clincher was that I got a contract to take over a project that had missed its delivery target and the software wasn't even close. The hard ware was all done and tested so there was huge financial pressure to deliver the machine. (usually I only get a job when every other alternative has been exhausted). The previous programmers had taken this approach. It was very, very slow. This ratified my prejudice. I took the job with the understanding I was to produce a working prototype in 30 days. I keep the C++ part and added on a gui with mfc. Made the deadline with a couple of days to spare.
And, I have to admit I'm still ticked off that the utiliy app that came with my wireless card has to be killed or, even while minimized, it uses up all the GDI objects in a few hours and crashes my machine. If you need to include some production code as an "Afterthought" java avoids really bad things like memory leaks etc...
The hassles with things like memory leaks, threading races, etc with this application were what led me to boost in the first place. That's how I got here. Currently I prefer to use boost for the "guts" and MFC for the "GUI viewer/manuiplator". But they don't always play nice together. This my core complaint with MFC. It's too coupled so you endup sucking in a lot of stuff you don't want. When I look at wxWidgets, QT, etc. I see they have classes for strings, multithreading, etc. This gives me pause as it would seem that the GUI layer might be coupled to other parts of the library which I would prefer to use boost for. I've also been looking at WTL (microsoft Windows Template Library) which looks like a thin templatized layer over Win32. I'm sort of limited in that I need a system which "just works" rather "can be made to work". Robert Ramey
On Apr 9, 2009, at 2:23 PM, Robert Ramey wrote:
Mike Marchywka wrote:
Have you considered java for the gui? You can get platform-look-and-feel etc but if your customers absolutely need it to look like Windoze, well... I wouldn't rec it for performance but if you need a gui it is safe and has a lot stuff and has a native interface. It is also a bit more portable than MFC LOL.
I was always turned off by java. My perception was that as an interpreted language it was going to be slower than C++. Why learn yet another language just to go slower.
The clincher was that I got a contract to take over a project that had missed its delivery target and the software wasn't even close. The hard ware was all done and tested so there was huge financial pressure to deliver the machine. (usually I only get a job when every other alternative has been exhausted). The previous programmers had taken this approach. It was very, very slow. This ratified my prejudice. I took the job with the understanding I was to produce a working prototype in 30 days. I keep the C++ part and added on a gui with mfc. Made the deadline with a couple of days to spare.
And, I have to admit I'm still ticked off that the utiliy app that came with my wireless card has to be killed or, even while minimized, it uses up all the GDI objects in a few hours and crashes my machine. If you need to include some production code as an "Afterthought" java avoids really bad things like memory leaks etc...
The hassles with things like memory leaks, threading races, etc with this application were what led me to boost in the first place. That's how I got here. Currently I prefer to use boost for the "guts" and MFC for the "GUI viewer/manuiplator". But they don't always play nice together. This my core complaint with MFC. It's too coupled so you endup sucking in a lot of stuff you don't want.
When I look at wxWidgets, QT, etc. I see they have classes for strings, multithreading, etc. This gives me pause as it would seem that the GUI layer might be coupled to other parts of the library which I would prefer to use boost for.
I've also been looking at WTL (microsoft Windows Template Library) which looks like a thin templatized layer over Win32.
I'm sort of limited in that I need a system which "just works" rather "can be made to work".
Have you looked at: http://smartwin.sourceforge.net/ I have never tried it (if I did Windows GUIs I would check it out) so I cannot vouch for it, but it sounds interesting: "SmartWin++ is a modern designed C++ library, it uses STL where possible and boost where needed..." "...We believe that STL and Boost are good tools and should be used in favor of creating your own bug-prone classes to substitute them! If it exists in Boost or in STL it does NOT exist in SmartWin++!! :)..." "... SmartWin++ does NOT try to solve your marriage problems. It cares only about GUI. If you need a network library, search elsewhere. SmartWin++ will not solve your TCP/IP problems or your HTTP problems or your Dijkstra's Extra problems! SmartWin++ is about GUI, nothing more, nothing less! We try to be the best in ONE area which is GUI development! This makes the library small, slick, fast and good looking! ;)" -- Michael
Have you looked at:
http://smartwin.sourceforge.net/
I have never tried it (if I did Windows GUIs I would check it out) so I cannot vouch for it, but it sounds interesting:
"SmartWin++ is a modern designed C++ library, it uses STL where possible and boost where needed..."
"...We believe that STL and Boost are good tools and should be used in favor of creating your own bug-prone classes to substitute them! If it exists in Boost or in STL it does NOT exist in SmartWin++!! :)..."
"... SmartWin++ does NOT try to solve your marriage problems. It cares only about GUI. If you need a network library, search elsewhere. SmartWin++ will not solve your TCP/IP problems or your HTTP problems or your Dijkstra's Extra problems! SmartWin++ is about GUI, nothing more, nothing less! We try to be the best in ONE area which is GUI development! This makes the library small, slick, fast and good looking! ;)"
-- Michael
It looks like this library hasn't been worked on in nearly 2 years.
On a couple of occasions I've seen teams abandon MFC for WTL, though the lack of documentation and the fact that it's not officially supported by Microsoft is a problem. On Thu, Apr 9, 2009 at 1:56 PM, Robert Ramey <ramey@rrsd.com> wrote:
Well, I guess I'm just an amazing guy.
Actually, I'm not all that happy with MFC. But whenver I consider something another alternative, I find them lacking. MFC is a huge body of code which is (mostly) well documented. I typically need and application to support some other project. Recent examples have been a GUI interface to and embedded system. My customers expect this "tail end" application to be doable in say two weeks or so. And they want it to "look like" a "standard" windows app including dockable tool bars, menus, email and web connectivity, support for things like file drag and drop. etc.
The only thing I see that can do this besides MFC is Visual Basic. I haven't looked at C#. But those have even bigger downsides.
As I said before, I have a lot of complaints about it, but I don't seen anything available that is nearly as comprehensive for windows application development.
Robert Ramey
peter_foelsche@agilent.com wrote:
last time I developed a GUI application for windows (in 1998), I was using C++ and Win32.
That might explain it.
We tried MFC and it just did not do it. I remember sick solutions for sick problems in MFC, like sending messages to be called back again later.
I simply wrote some C++ wrappers for win32 calls. And I joined these wrappers into base class and member class relationships. The resulting code was very clear, short and maintainable. It contained an activex control container (written in C++) -- not using ATL.
I'm amazed that there are still C++ programmers, which don't know about how to wrap a fallible Win32 resource into a C++ class and how to chain such classes into base and member class relationships.
I'm amazed that there still seem to be C++ programmers, which don't know how to abort the construction of an object.
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Thursday, April 09, 2009 12:17 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Boost thread conflicts with MFC
aaaaa .... what do you use instead for development of a C++ windows GUI program?
Robert Ramey
peter_foelsche@agilent.com wrote:
It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
I've found WTL to be very useful in getting a GUI app up and running. The company that I work for uses it for a fairly large commercial application. It's a relatively light-weight wrapper for the Windows GUI. WTL is open source, and has been for several years: http://sourceforge.net/projects/wtl/ There is a support list on Yahoo! Groups: http://tech.groups.yahoo.com/group/wtl/ It has a fair amount of sample source, and some extensions. There are also some WTL resources available on CodeProject.com. Disclosure: I am the moderator of the Yahoo group, and a member of the project on SourceForge. Development activity on the project has been fairly low for a while, and I'm not sure what the intent is for a new version (the latest is coming up on two years old). John
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Emil Dotchevski Sent: Thursday, April 09, 2009 3:10 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Boost thread conflicts with MFC
On a couple of occasions I've seen teams abandon MFC for WTL, though the lack of documentation and the fact that it's not officially supported by Microsoft is a problem.
On Thu, Apr 9, 2009 at 1:56 PM, Robert Ramey <ramey@rrsd.com> wrote:
Well, I guess I'm just an amazing guy.
Actually, I'm not all that happy with MFC. But whenver I consider something another alternative, I find them lacking. MFC is a huge body of code which is (mostly) well documented. I typically need and application to support some other project. Recent examples have been a GUI interface to and embedded system. My customers expect this "tail end" application to be doable in say two weeks or so. And they want it to "look like" a "standard" windows app including dockable tool bars, menus, email and web connectivity, support for things like file drag and drop. etc.
The only thing I see that can do this besides MFC is Visual Basic. I haven't looked at C#. But those have even bigger downsides.
As I said before, I have a lot of complaints about it, but I don't seen anything available that is nearly as comprehensive for windows application development.
Robert Ramey
peter_foelsche@agilent.com wrote:
last time I developed a GUI application for windows (in 1998), I was using C++ and Win32.
That might explain it.
We tried MFC and it just did not do it. I remember sick solutions for sick problems in MFC, like sending messages to be called back again later.
I simply wrote some C++ wrappers for win32 calls. And I joined these wrappers into base class and member class relationships. The resulting code was very clear, short and maintainable. It contained an activex control container (written in C++) -- not using ATL.
I'm amazed that there are still C++ programmers, which don't know about how to wrap a fallible Win32 resource into a C++ class and how to chain such classes into base and member class relationships.
I'm amazed that there still seem to be C++ programmers, which don't know how to abort the construction of an object.
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Thursday, April 09, 2009 12:17 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Boost thread conflicts with MFC
aaaaa .... what do you use instead for development of a C++ windows GUI program?
Robert Ramey
peter_foelsche@agilent.com wrote:
It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Fri, Apr 10, 2009 at 12:21 PM, <peter_foelsche@agilent.com> wrote:
peter_foelsche@agilent.com wrote:
last time I developed a GUI application for windows (in 1998), I was using C++ and Win32.
That might explain it.
you mean, MFC has dramatically changed meanwhile?
While I don't advocate MFC (I suggest ATL or WTL), MFC was version 6.x in 1998. There have been 6 releases since then, and it's now at version 9.x. Quote for the latest one from Microsoft's Download Center: "The VC++ 2008 MFC libraries have been extended to support creation of applications that have: * Office Ribbon style interface * Office 2007, Office 2003 and Office XP look and feel * Modern Visual Studio-style docking toolbars and panes * Fully customizable toolbars and menus * A rich set of advanced GUI controls * Advanced MDI tabs and groups * And much more!" Robert, one of the nice things about ATL is that it doesn't require that your application ship with support DLLs like MFC requires. ATL also uses constructors to initialize objects, instead of two-phase initialization like MFC. --Michael Fawcett
Michael Fawcett wrote:
On Fri, Apr 10, 2009 at 12:21 PM, <peter_foelsche@agilent.com> wrote:
peter_foelsche@agilent.com wrote:
last time I developed a GUI application for windows (in 1998), I was using C++ and Win32.
That might explain it.
you mean, MFC has dramatically changed meanwhile?
While I don't advocate MFC (I suggest ATL or WTL), MFC was version 6.x in 1998. There have been 6 releases since then, and it's now at version 9.x.
Quote for the latest one from Microsoft's Download Center:
"The VC++ 2008 MFC libraries have been extended to support creation of applications that have:
* Office Ribbon style interface
* Office 2007, Office 2003 and Office XP look and feel
* Modern Visual Studio-style docking toolbars and panes
* Fully customizable toolbars and menus
* A rich set of advanced GUI controls
* Advanced MDI tabs and groups
* And much more!"
Actually for me one should add * context sensitive help * support for addng 3rd party controls * black box support of COM automation * free support for file system stuff * idiot proof implemenations for things like and internet connection with http protocol * complete and consistent documentation with the same practice and format throughout. But this all comes with a cost - conflict with other libraries. It's not that I'm all the crazy about this stuff. It's just that the people I do this for expect a "professional looking application" (That is some thing that looks like the applications they are used to). And that won't pay me to spend any thing more than the minimum time required to get it done. So I'm addicted to libraries of all kinds.
Robert, one of the nice things about ATL is that it doesn't require that your application ship with support DLLs like MFC requires.
with the installation of VC 9.0 on my system - this has suddenly - without warning - become a huge problem for me. I downloaded WTL sometime ago and liked the fact that it would probably be easier for me since I'm familiar with MFC. I expect that I will try this in the future. I realise that what I really want is what everyone really wants. A platform independent GUI library which does what MFC, VB, etc do. Use a wizard to generate a skeletal application, Layout a GUI, automatically generate a working app, fill in the hooks to the backend code. Oh and don't forget real documentation with sample applications. Microsoft has done this - but its a love/hate thing. It works but then I have to deal with a few hacks with every project to get everything to play together. I suppose that's why we earn the big bucks.
ATL also uses constructors to initialize objects, instead of two-phase initialization like MFC.
I'll look into it. Robert Ramey
--Michael Fawcett
Robert Ramey wrote:
I realise that what I really want is what everyone really wants. A platform independent GUI library which does what MFC, VB, etc do. Use a wizard to generate a skeletal application, Layout a GUI, automatically generate a working app, fill in the hooks to the backend code. Oh and don't forget real documentation with sample applications. Microsoft has done this - but its a love/hate thing. It works but then I have to deal with a few hacks with every project to get everything to play together. I suppose that's why we earn the big bucks.
Robert Ramey
What I don't understand is why nearly every C++ GUI framework out there tries to be the next C++ standard in that they all provide strings, containers, network classes, xml parsers, etc. If you already have a code base, you have to write simple wrappers around everything just so you can communicate with the GUI library. SmartWin++ looked like it definitely had the right philosophy but sadly, it appears to be abandoned in favor of some ajax project by the authors. Cppgui looks promising too but it is pretty new and incomplete
On Apr 11, 2009, at 12:49 AM, Raindog wrote:
[...] What I don't understand is why nearly every C++ GUI framework out there tries to be the next C++ standard in that they all provide strings, containers, network classes, xml parsers, etc. If you already have a code base, you have to write simple wrappers around everything just so you can communicate with the GUI library.
I agree 100%....this seems to be an (unfortunate) trend with many libraries (not only in regards to GUI development either). Sometimes I look at the facilities of a certain library and you can literally see the questions marks on my face once I hit things that barely have to do with the original target of the library.
SmartWin++ looked like it definitely had the right philosophy but sadly, it appears to be abandoned in favor of some ajax project by the authors. Cppgui looks promising too but it is pretty new and incomplete
Thay may actually be a result of not being considered for real projects. I certainly cannot speak for the owners of SmartWin++ however, one really wonders if acceptance of a library grows once it adds more and more (hardly related or unrelated) stuff to it. Or whether it is more like a *ego* thing in building the ultimate one and only library. Certainly I don't imply any offense to any library creator/developer/ maintainer...it just some things I try to understand.... Ciao, Andreas
Few years ago there was a very long discussion about potential boost.gui library: http://lists.boost.org/Archives/boost/2003/07/50400.php Unfortunately, it faded with no practical results...
Andreas Masur wrote:
On Apr 11, 2009, at 12:49 AM, Raindog wrote:
[...] What I don't understand is why nearly every C++ GUI framework out there tries to be the next C++ standard in that they all provide strings, containers, network classes, xml parsers, etc. If you already have a code base, you have to write simple wrappers around everything just so you can communicate with the GUI library.
I agree 100%....this seems to be an (unfortunate) trend with many libraries (not only in regards to GUI development either).
Unfortunately some of these libraries are old. MFC and WxWindows have their own Strings classes because they needed them before the standards solidified or were well supported. This is just the cost of getting something done. In some cases, the interface propagated through the entire system and can't be easily removed, in others cases, the classes are just there for backward compatibility and can be ignored. WxWindows is a nice cross platform gui toolkit, but when you are targeting MS windows, the native toolkits make it much easier to produce polished apps. Carl -- Carl Zmola czmola@woti.com
On Thu, Apr 9, 2009 at 4:16 PM, Robert Ramey <ramey@rrsd.com> wrote:
aaaaa .... what do you use instead for development of a C++ windows GUI program?
I use cppgui (http://www.assembla.com/wiki/show/cppgui) and I implement the widgets as I go along.
Robert Ramey
[snip] -- Felipe Magno de Almeida
Robert Ramey wrote:
aaaaa .... what do you use instead for development of a C++ windows GUI program?
C++/CLI. It is an extension to C++. It is a RAD language which makes GUI design much easier than MFC. It is a better .Net language than C# and will do .Net GUI using Windows Forms. One can easily mix standard C++ libraries/code with it. But the poster who assumed that Microsoft no longer supports MFC is completely wrong, even though I also dislike MFC. They are actually putting almost all C++ work into MFC, mainly because Microsoft will never allow C++/CLI to seriously compete with their own .Net langauge, C#, even though C++/CLI is a superior .Net language thanks to Herb Sutter.
Robert Ramey
peter_foelsche@agilent.com wrote:
It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources.
What does exception handling have to do with whether one uses MFC or not? ________________________________ From: "peter_foelsche@agilent.com" <peter_foelsche@agilent.com> To: boost-users@lists.boost.org Sent: Thursday, April 9, 2009 1:59:55 PM Subject: Re: [Boost-users] Boost thread conflicts with MFC It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
MFC uses methods instead of constructors to initialize objects. ________________________________ From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of console shark Sent: Thursday, April 09, 2009 13:05 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Boost thread conflicts with MFC What does exception handling have to do with whether one uses MFC or not? ________________________________ From: "peter_foelsche@agilent.com" <peter_foelsche@agilent.com> To: boost-users@lists.boost.org Sent: Thursday, April 9, 2009 1:59:55 PM Subject: Re: [Boost-users] Boost thread conflicts with MFC It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
Andreas Masur -
Anthony Williams -
Carl Zmola -
console shark -
Edward Diener -
Emil Dotchevski -
Felipe Magno de Almeida -
Igor MI -
Igor R -
John Wilkinson -
Michael Fawcett -
Michael Olea -
Mike Marchywka -
peter_foelsche＠agilent.com -
Raindog -
Ray Burkholder -
Robert Ramey -
tinkertom