Structuring code for large gui apps

[fg23]

I'm wondering what the people on this board suggest as a good way of structuring code for large gui apps. My current project has a main overlapped window with a number if child tool windows and an editor window. I need to structure the code so each window is seperate from the others but can interact globally.

Any advice for me?

[freddie1]

Any advice for me?

Absolutely. However, whether or not you'll be able to use it depends on whether or not you do Win32 SDK style app development, because that is what I do, and my advice likely wouldn't apply well or at all to other development frameworks.

The fundamentals of my approach are to register a seperate Window Class for each distinct type of window I'm going to create. What this will in turn do is require a seperate Window Procedure for each main overlapped window. In terms of app code organization this will translate into a seperate *.h and *.cpp file for each form/dialog/window. So right at the start you have a basis of code organization that reflects well the different logic for the different things each form/dialog/windoiw is tasked to do. I have a very small demo app showing this here....

http://www.jose.it-berater.org/smfforum/index.php?topic=3392.0

It is in my ProgEx40 series of projects - post #5.

Another issue is the transferal of data between the various forms/dialogs/windows. These are all 'objects' in every sense, and should only have access to the data they need to do whatever it is they do. The Windows Api contains methods for transfering data between window objects usings pointers to dynamically allocated memory. I would recommend doing this as opposed to using globally accessable data. The above tutorial shows in simplified form how to do that. Hope this info helps.

[fg23]

That is very helpful, thank you. I especially like how you handle events. Yes I am using pure winapi. I already create seperate window classes for each window. I tried in the past to put code for each window in seperate .h and .cpp file but I kept ending up with errors about functions being defined multiple times so currently I have all code in a single .cpp file. I'll try it again using your code as a base.

Another issue is the transferal of data between the various forms/dialogs/windows. These are all 'objects' in every sense, and should only have access to the data they need to do whatever it is they do. The Windows Api contains methods for transfering data between window objects usings pointers to dynamically allocated memory. I would recommend doing this as opposed to using globally accessable data. The above tutorial shows in simplified form how to do that. Hope this info helps.

This is what i'm most interested in now. Could you elaborate on the method for transferring data or point me to the section of your code that uses it? I'm not sure what to look for. Currently i'm using global variables.

Oh and another thing.. How do you decide when to use multiple threads? I understand the concepts of threads and I know how to create them but I have no idea why I why ever use them.

[freddie1]

This is what i'm most interested in now. Could you elaborate on the method for transferring data or point me to the section of your code that uses it? I'm not sure what to look for. Currently i'm using global variables.

I'd recommend you start with my ProgEx37 then, which explains all that in detail. Some of it may be review for you, but embedded in all that is the info you need. That fifth post in the ProgEx40 material was just more or less an brief excursion from the main ProgEx40 example, which also used multiple forms. But it specifically addressed your question in as simple a manner as possible. Having you projects broken into multiple files is one of those things you just have to learn, because it is standard practice for one thing, and in large projects you really need to organize your code in some way that you don't have 50000 line code files. It just becomes too unwieldly.

There is something termed the 'tenth second rule'. Supposedly, if some element of processing is going to take more than a tenth of a second, it might be wise to consider using a worker thread for the processing. In that way your UI will remain responsive to the user. Otherwise, your window procedure will be fully tied up in whatever lengthy processing it is running, and the user will tend to think your app is locked up. A cheap way out is to do the hourglass thing, but that doesn't help the user do anything else. Threading can get complicated. I'd recommend you get some of the other stuff down first.