Owner Draw Static Control Freezes up application
-
Hi I have successfully Created a bitmap in my static control thru Overriding CStatic::DrawItem problem is it freezes my application I know why Draw Item is constantly Being Called When I SetRedraw(FALSE)I can see it, However when a window covers the bitmap it gets erased There is I am missing I am not sure what it is
-
Hi I don't get this but CStatic::DrawItem is a override in Win32 WM_CTLCOLOR is a message So I got to thinking once I overrode CStatic::DrawItem I don't need a message map I moved other windows over my CStatc Bitmap and it remained intact no freeze up
MFC is weird in a number of areas it isn't equivalent to the WIN32 API in a great many respects. You have run across this a number of times with things like it is a singular thread, it's modal dialogs are in fact not WIN32 modal in MFC they become modal via the message loop. You seem to have identified MFC static text has got some different behaviour as well. The thing about SS_OWNERDRAW on a true Win32 static class is you don't override it on the static itself but rather the dialog owner is sent the WM_DRAWITEM message and it is expected to handle it for the static class In the Win32 framework it is very explicit About Static Controls (Windows)[^]
By using the SS_OWNERDRAW style, an application can take responsibility for painting a static control. The parent window of an owner-drawn static control (its owner) receives a WM_DRAWITEM message whenever the static control needs to be painted. The message includes a pointer to a DRAWITEMSTRUCT structure that contains information that the owner window uses when drawing the control.
My biggest reason for not ever using MFC is that you can't mix pure Win32 code with MFC easily and reliably. The newer WPF framework allows Win32 Interoperation with only a limited few restrictions. For example in your case it would have been nice to have just written a nice pure Win32 dialog code to do what you want but MFC can't call a native Win32 dialog process because it has its own message pump loop and it's dialogs aren't really modal. If you want to look at the message pump which is very MFC specific goto CWnd::RunModalLoop function and you can see how it pumps messages into the framework via
AfxGetThread()->PumpMessage()
If you are using MFC you need to ignore native Win32 it won't always work. Probably use it as a guide as how it might work if MFC not as how you should do it on MFC. From you prior answer it is also obvious MFC window frames aren't exactly like Win32 native frame either. If your project isn't large I think you have now reached a level of understanding of Win32 you could dispense with the MFC framework and just have a pure Win32 application. You seem to spend more time fighting the framework than actually coding new stuff. So the question
-
MFC is weird in a number of areas it isn't equivalent to the WIN32 API in a great many respects. You have run across this a number of times with things like it is a singular thread, it's modal dialogs are in fact not WIN32 modal in MFC they become modal via the message loop. You seem to have identified MFC static text has got some different behaviour as well. The thing about SS_OWNERDRAW on a true Win32 static class is you don't override it on the static itself but rather the dialog owner is sent the WM_DRAWITEM message and it is expected to handle it for the static class In the Win32 framework it is very explicit About Static Controls (Windows)[^]
By using the SS_OWNERDRAW style, an application can take responsibility for painting a static control. The parent window of an owner-drawn static control (its owner) receives a WM_DRAWITEM message whenever the static control needs to be painted. The message includes a pointer to a DRAWITEMSTRUCT structure that contains information that the owner window uses when drawing the control.
My biggest reason for not ever using MFC is that you can't mix pure Win32 code with MFC easily and reliably. The newer WPF framework allows Win32 Interoperation with only a limited few restrictions. For example in your case it would have been nice to have just written a nice pure Win32 dialog code to do what you want but MFC can't call a native Win32 dialog process because it has its own message pump loop and it's dialogs aren't really modal. If you want to look at the message pump which is very MFC specific goto CWnd::RunModalLoop function and you can see how it pumps messages into the framework via
AfxGetThread()->PumpMessage()
If you are using MFC you need to ignore native Win32 it won't always work. Probably use it as a guide as how it might work if MFC not as how you should do it on MFC. From you prior answer it is also obvious MFC window frames aren't exactly like Win32 native frame either. If your project isn't large I think you have now reached a level of understanding of Win32 you could dispense with the MFC framework and just have a pure Win32 application. You seem to spend more time fighting the framework than actually coding new stuff. So the question
-
MFC is weird in a number of areas it isn't equivalent to the WIN32 API in a great many respects. You have run across this a number of times with things like it is a singular thread, it's modal dialogs are in fact not WIN32 modal in MFC they become modal via the message loop. You seem to have identified MFC static text has got some different behaviour as well. The thing about SS_OWNERDRAW on a true Win32 static class is you don't override it on the static itself but rather the dialog owner is sent the WM_DRAWITEM message and it is expected to handle it for the static class In the Win32 framework it is very explicit About Static Controls (Windows)[^]
By using the SS_OWNERDRAW style, an application can take responsibility for painting a static control. The parent window of an owner-drawn static control (its owner) receives a WM_DRAWITEM message whenever the static control needs to be painted. The message includes a pointer to a DRAWITEMSTRUCT structure that contains information that the owner window uses when drawing the control.
My biggest reason for not ever using MFC is that you can't mix pure Win32 code with MFC easily and reliably. The newer WPF framework allows Win32 Interoperation with only a limited few restrictions. For example in your case it would have been nice to have just written a nice pure Win32 dialog code to do what you want but MFC can't call a native Win32 dialog process because it has its own message pump loop and it's dialogs aren't really modal. If you want to look at the message pump which is very MFC specific goto CWnd::RunModalLoop function and you can see how it pumps messages into the framework via
AfxGetThread()->PumpMessage()
If you are using MFC you need to ignore native Win32 it won't always work. Probably use it as a guide as how it might work if MFC not as how you should do it on MFC. From you prior answer it is also obvious MFC window frames aren't exactly like Win32 native frame either. If your project isn't large I think you have now reached a level of understanding of Win32 you could dispense with the MFC framework and just have a pure Win32 application. You seem to spend more time fighting the framework than actually coding new stuff. So the question
To Answer your question When looking at Windows apps almost all are C++ just look at the articles examples on The CodeProject What % is Win32 and how much is MFC I would say 80 % of the Windows examples are MFC why is that ? Of course now C# seems the way to go by that is for Web Development What do most people use for Windows Developement ?
-
To Answer your question When looking at Windows apps almost all are C++ just look at the articles examples on The CodeProject What % is Win32 and how much is MFC I would say 80 % of the Windows examples are MFC why is that ? Of course now C# seems the way to go by that is for Web Development What do most people use for Windows Developement ?
ForNow wrote:
What do most people use for Windows Developement ?
I use pure Win32 from C++ and find it works just fine. I used to write MFC in my professional life but found it over complicated in many areas. I also use C# and find that so much easier, and more powerful than MFC.
-
ForNow wrote:
What do most people use for Windows Developement ?
I use pure Win32 from C++ and find it works just fine. I used to write MFC in my professional life but found it over complicated in many areas. I also use C# and find that so much easier, and more powerful than MFC.
-
To Answer your question When looking at Windows apps almost all are C++ just look at the articles examples on The CodeProject What % is Win32 and how much is MFC I would say 80 % of the Windows examples are MFC why is that ? Of course now C# seems the way to go by that is for Web Development What do most people use for Windows Developement ?
There are more in MFC because it is technically easier for the amateur to play with. In the same way Visual Basic has a following and takes up a lot of programming space for what it really is. Your coding is now clearly moving well beyond amateur and you clearly grasp what is actually happening at the lower levels so there is no reason you couldn't get rid of the training wheels being provided by MFC. Commercially it isn't about what is more used it is what will survive over time. So long as Windows exists you will be able to port code written on native Win32 API and the Win64 API system already fully supports all the Win32 API. In fact the old original Win16 API is still pretty much supported intact in both these systems. It's the simple reason companies spending serious bucks on coding that is expected to last a long time insist on it. Now if you are playing in short lived markets like games, webpages etc you don't worry about that so much. Given you have got your head around the API something most amateurs struggle with to me at least it just seems silly to not code on it especially if you are doing this commercially. On large scale Commercial windows programs you will be almost always be on Native Win32/Win64 (possibly with .NET) unless you are playing with a very specific market. A quick look at Microsoft/IBM and strangely even google programmer demographics shows you that. The other major thing that same majority can do is program in Java. The reason you choose any framework should always be for speed of development but the downside is the framework is always a liability for ongoing support. If all you are using MFC is to create dialog and windows layouts you would be better off using a Resource Editor to visually lay up the windows/dialogs and then directly load the resource files. Both C# and WPF framework use this trick but most of us old timers do it that way with code stubs we have written. I have a couple of functions in my private library that can read RES/RC or dialog resource DLL files and return to you the constructed window when requested. The formats are really not challenging and it's all well documented on the internet. I use Resource Builder from Microsoft which has a price tag but if you want to play with the idea, OpenWatcom C++ and LCC_32 have free resource editors and are free to play with. You can load save .RC or .RES files directly from the visual editors. If you want some stubs to load the files at runtime I am happy to provide some functions.
In v
-
There are more in MFC because it is technically easier for the amateur to play with. In the same way Visual Basic has a following and takes up a lot of programming space for what it really is. Your coding is now clearly moving well beyond amateur and you clearly grasp what is actually happening at the lower levels so there is no reason you couldn't get rid of the training wheels being provided by MFC. Commercially it isn't about what is more used it is what will survive over time. So long as Windows exists you will be able to port code written on native Win32 API and the Win64 API system already fully supports all the Win32 API. In fact the old original Win16 API is still pretty much supported intact in both these systems. It's the simple reason companies spending serious bucks on coding that is expected to last a long time insist on it. Now if you are playing in short lived markets like games, webpages etc you don't worry about that so much. Given you have got your head around the API something most amateurs struggle with to me at least it just seems silly to not code on it especially if you are doing this commercially. On large scale Commercial windows programs you will be almost always be on Native Win32/Win64 (possibly with .NET) unless you are playing with a very specific market. A quick look at Microsoft/IBM and strangely even google programmer demographics shows you that. The other major thing that same majority can do is program in Java. The reason you choose any framework should always be for speed of development but the downside is the framework is always a liability for ongoing support. If all you are using MFC is to create dialog and windows layouts you would be better off using a Resource Editor to visually lay up the windows/dialogs and then directly load the resource files. Both C# and WPF framework use this trick but most of us old timers do it that way with code stubs we have written. I have a couple of functions in my private library that can read RES/RC or dialog resource DLL files and return to you the constructed window when requested. The formats are really not challenging and it's all well documented on the internet. I use Resource Builder from Microsoft which has a price tag but if you want to play with the idea, OpenWatcom C++ and LCC_32 have free resource editors and are free to play with. You can load save .RC or .RES files directly from the visual editors. If you want some stubs to load the files at runtime I am happy to provide some functions.
In v
I originally wrote the program I was working on in C wanting to learn C++ I choose to re-write and use MFC I am by trade a mainframe Assembler programmer and through out time I always wanted to get to the MainStream Doing it on your own time is difficult If you can send me the resource builder would appreciate it I can show EXACTLY (.png images) what i been working on (its really neat) My e-mail is reichmanjoe@gmail.com Thanks
-
When you say you use Win32 C++ you develop your own Classes ? You say C# is more power full how so it doesn't have pointers from what I understand
ForNow wrote:
...it doesn't have pointers from what I understand
And that makes a language powerful? Some find pointers, especially those that point to other pointers, a deterrent. It all depends on the person wielding the tool, not the tool itself.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
When you say you use Win32 C++ you develop your own Classes ? You say C# is more power full how so it doesn't have pointers from what I understand
Yes, I created a simple framework of my own, but I often just write without my own classes. C# does have pointers (as does Java, Python, Javascript etc.), they are just called references. The terminology is slightly different but once you understand what they are, it all makes perfect sense.
-
I originally wrote the program I was working on in C wanting to learn C++ I choose to re-write and use MFC I am by trade a mainframe Assembler programmer and through out time I always wanted to get to the MainStream Doing it on your own time is difficult If you can send me the resource builder would appreciate it I can show EXACTLY (.png images) what i been working on (its really neat) My e-mail is reichmanjoe@gmail.com Thanks
ForNow wrote:
If you can send me the resource builder would appreciate it
- That would be illegal since it's not a free product. 2) Aren't you using Visual Studio?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
ForNow wrote:
If you can send me the resource builder would appreciate it
- That would be illegal since it's not a free product. 2) Aren't you using Visual Studio?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
I do I thought it was leon personal code I have been using The Wizard Lately to Develop my Dialog Boxes David I need to know do you use MFC or Win32 Thanks
ForNow wrote:
I have been using The Wizard Lately to Develop my Dialog Boxes
I assume you mean Visual Studio's built-in resource editor. If so, what is it not doing that you are needing a replacement?
ForNow wrote:
David I need to know do you use MFC or Win32
Both.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
ForNow wrote:
I have been using The Wizard Lately to Develop my Dialog Boxes
I assume you mean Visual Studio's built-in resource editor. If so, what is it not doing that you are needing a replacement?
ForNow wrote:
David I need to know do you use MFC or Win32
Both.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
Nothing... What Doesn't come out Right the Text in The Static Text I edit by hand Thought leon had something better
ForNow wrote:
...the Text in The Static Text I edit by hand
Please elaborate.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
ForNow wrote:
...the Text in The Static Text I edit by hand
Please elaborate.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
When I drag a Static Text to my Dialog and I Drag the corners sometimes the text get chopped off So I manually edit the .rc file its a lot easier
Clearing some confusions between Richard and yourself. The free version of Visual Studio doesn't have the visual resource editor. It only has the resource view window in the IDE that allows you to see the names in the RC file, but does not let you visually edit it. If you only have the free version of VS you will never have seen the visual resource editor. That aside all any visual resource editor does is allow you to play around visually with the files in the RC file and then save that file. Things that drive you nuts like TAB order, or aligning text inside or around bitmap backgrounds or text cutting off like you described. As I said there are a couple of free options that will allow you to do that if you haven't seen the visual editor it's worth looking at. Now I will explain the real world complication when you do this commercially for a product. The default setup for Visual Studio is to bind your resources directly into your EXE. The first obvious fallout is as the size of your resource file increases so does your EXE file and that can become problematic. Now if you are just using dialog templates and resource ID's, they are tiny and I wouldn't worry. However if you are using lots of bitmaps and icons in resource form that is another thing entirely. The old Win16 exe stub format had the good sense to limit the bound resource size to 64K but win32 allows a full 4GB which is a bit crazy. I sometimes run across 2GB+ EXE from amateurs and the moment you see it you know what is in it, lots and lots of graphic resources. It doesn't even usually dawn on them that having a 2GB EXE is putting stress on windows itself. The second problem we usually face commercially is human language and monitor specifics. We need different text, fonts and bitmaps for different countries and often different setups for different aspect monitors. So you either need some clever installer, or at runtime you detect windows language and monitor scalings and then load different resources appropriately. The later is almost always how all Microsofts own products do it. So commercially for large projects the EXE itself usually only binds limited vital resources, all the rest of the resources are bound in at runtime either from File/DLL. Once you have done the code to do that feature, you will find you will always tend to use that rather than resources in your EXE because frankly it's faster and easier. You get a nice clean separation between resources and code and you can manage both independently.
In vino v
-
Clearing some confusions between Richard and yourself. The free version of Visual Studio doesn't have the visual resource editor. It only has the resource view window in the IDE that allows you to see the names in the RC file, but does not let you visually edit it. If you only have the free version of VS you will never have seen the visual resource editor. That aside all any visual resource editor does is allow you to play around visually with the files in the RC file and then save that file. Things that drive you nuts like TAB order, or aligning text inside or around bitmap backgrounds or text cutting off like you described. As I said there are a couple of free options that will allow you to do that if you haven't seen the visual editor it's worth looking at. Now I will explain the real world complication when you do this commercially for a product. The default setup for Visual Studio is to bind your resources directly into your EXE. The first obvious fallout is as the size of your resource file increases so does your EXE file and that can become problematic. Now if you are just using dialog templates and resource ID's, they are tiny and I wouldn't worry. However if you are using lots of bitmaps and icons in resource form that is another thing entirely. The old Win16 exe stub format had the good sense to limit the bound resource size to 64K but win32 allows a full 4GB which is a bit crazy. I sometimes run across 2GB+ EXE from amateurs and the moment you see it you know what is in it, lots and lots of graphic resources. It doesn't even usually dawn on them that having a 2GB EXE is putting stress on windows itself. The second problem we usually face commercially is human language and monitor specifics. We need different text, fonts and bitmaps for different countries and often different setups for different aspect monitors. So you either need some clever installer, or at runtime you detect windows language and monitor scalings and then load different resources appropriately. The later is almost always how all Microsofts own products do it. So commercially for large projects the EXE itself usually only binds limited vital resources, all the rest of the resources are bound in at runtime either from File/DLL. Once you have done the code to do that feature, you will find you will always tend to use that rather than resources in your EXE because frankly it's faster and easier. You get a nice clean separation between resources and code and you can manage both independently.
In vino v
-
Clearing some confusions between Richard and yourself. The free version of Visual Studio doesn't have the visual resource editor. It only has the resource view window in the IDE that allows you to see the names in the RC file, but does not let you visually edit it. If you only have the free version of VS you will never have seen the visual resource editor. That aside all any visual resource editor does is allow you to play around visually with the files in the RC file and then save that file. Things that drive you nuts like TAB order, or aligning text inside or around bitmap backgrounds or text cutting off like you described. As I said there are a couple of free options that will allow you to do that if you haven't seen the visual editor it's worth looking at. Now I will explain the real world complication when you do this commercially for a product. The default setup for Visual Studio is to bind your resources directly into your EXE. The first obvious fallout is as the size of your resource file increases so does your EXE file and that can become problematic. Now if you are just using dialog templates and resource ID's, they are tiny and I wouldn't worry. However if you are using lots of bitmaps and icons in resource form that is another thing entirely. The old Win16 exe stub format had the good sense to limit the bound resource size to 64K but win32 allows a full 4GB which is a bit crazy. I sometimes run across 2GB+ EXE from amateurs and the moment you see it you know what is in it, lots and lots of graphic resources. It doesn't even usually dawn on them that having a 2GB EXE is putting stress on windows itself. The second problem we usually face commercially is human language and monitor specifics. We need different text, fonts and bitmaps for different countries and often different setups for different aspect monitors. So you either need some clever installer, or at runtime you detect windows language and monitor scalings and then load different resources appropriately. The later is almost always how all Microsofts own products do it. So commercially for large projects the EXE itself usually only binds limited vital resources, all the rest of the resources are bound in at runtime either from File/DLL. Once you have done the code to do that feature, you will find you will always tend to use that rather than resources in your EXE because frankly it's faster and easier. You get a nice clean separation between resources and code and you can manage both independently.
In vino v
leon de boer wrote:
Clearing some confusions between Richard and yourself.
Can't see anything in my messages that you may be referring to. I made no mention of the resource editor, and it's pretty obvious from OP's messages that he is using a version of VS that does include it.
-
MFC is weird in a number of areas it isn't equivalent to the WIN32 API in a great many respects. You have run across this a number of times with things like it is a singular thread, it's modal dialogs are in fact not WIN32 modal in MFC they become modal via the message loop. You seem to have identified MFC static text has got some different behaviour as well. The thing about SS_OWNERDRAW on a true Win32 static class is you don't override it on the static itself but rather the dialog owner is sent the WM_DRAWITEM message and it is expected to handle it for the static class In the Win32 framework it is very explicit About Static Controls (Windows)[^]
By using the SS_OWNERDRAW style, an application can take responsibility for painting a static control. The parent window of an owner-drawn static control (its owner) receives a WM_DRAWITEM message whenever the static control needs to be painted. The message includes a pointer to a DRAWITEMSTRUCT structure that contains information that the owner window uses when drawing the control.
My biggest reason for not ever using MFC is that you can't mix pure Win32 code with MFC easily and reliably. The newer WPF framework allows Win32 Interoperation with only a limited few restrictions. For example in your case it would have been nice to have just written a nice pure Win32 dialog code to do what you want but MFC can't call a native Win32 dialog process because it has its own message pump loop and it's dialogs aren't really modal. If you want to look at the message pump which is very MFC specific goto CWnd::RunModalLoop function and you can see how it pumps messages into the framework via
AfxGetThread()->PumpMessage()
If you are using MFC you need to ignore native Win32 it won't always work. Probably use it as a guide as how it might work if MFC not as how you should do it on MFC. From you prior answer it is also obvious MFC window frames aren't exactly like Win32 native frame either. If your project isn't large I think you have now reached a level of understanding of Win32 you could dispense with the MFC framework and just have a pure Win32 application. You seem to spend more time fighting the framework than actually coding new stuff. So the question
I'm not a huge fan of MFC but have used it extensively in the past. I never had trouble mixing Win32 and MFC at all, in fact I found doing so essential and just part of a regular day MFCing.
Steve