|
I have a typical MFC MDI application that was built with the wizards. I have been using the resources as they are provided but I am now faced with the need to be able to compile/maintain the same code base with multiple application identities (this includes company name, application name, application title, file extensions, icons, verbs, etc...).
Some of this will be handled by maintaining multiple installer solutions to handle file associations, registry stuff, verbs, etc...) but I have not figured out how to handle the stuff that exists in the resource files. For example, the string for IDR_MAINFRAME and AFX_IDS_APP_TITLE need to be sensitive to a preprocessor directive or something similar in nature.
I'm guessing if I try messing with the .rc file directly, I will have trouble as I edit stuff via the GUI down the road.
Is there a way to modify some of those resources based on a preprocessor directive(or something similar) without introducing maintenance isssues?
|
|
|
|
|
You can add preprocessor directives (#define, #if, #endif) to your resource files as long as you do it outside of any blocks that are managed by the IDE. If you open the project's .rc file you should be able to figure out where to do it. In fact, if memory serves, there is a second user editable resource (projectname.rc2 I think) in MFC projects.
|
|
|
|
|
Looks like that will work for the strings and maybe a few other things as I'm not getting any errors.
I was hesitant because I've had nothing but trouble over the years when messing with the .rc files. Usually I was trying to copy dialogs from one project to another and tended to get corrupt looking results when I did that.
I needed some peer support to know that technique is common enough to carry on.
Thanks for taking the time to share your thoughts.
|
|
|
|
|
Ah crud. I spoke too soon. (I had only compiled it and did not try to run it when I replied earlier)
I removed those two string resources, IDR_MAINFRAME and AFX_IDS_APP_TITLE, from the .rc file and put them in the .rc2 file.
If I simply place them in there, in a STRINGTABLE, the application works correctly (has the correct title and such).
However, once I try to put a preprocessor directive in there, it compiles but the values will be incorrect sometimes depending on which value is in the if branch and the else branch.
After some experimentation, it appears that the last string assigment wins. I'm guessing that means it is ignoring the preprocessor directives or my symbol is not defined yet. I defined the symbol way up toward the top in my stdafx.h file but I'm guessing this isn't early enough?
You don't happen to remember where you defined your symbol when you had the need to do something like this?
I apologize for the extra question.
|
|
|
|
|
bob16972 wrote: I removed those two string resources, IDR_MAINFRAME and AFX_IDS_APP_TITLE, from the .rc file and put them in the .rc2 file.
Probably not a good idea as these are auto generated and maintained; especially be careful with anything with the prefix AFX.
bob16972 wrote: I defined the symbol way up toward the top in my stdafx.h file
I don't think stdafx.h gets included into the .rc fie. You should use some other header, or put the values direct into the resource script.
|
|
|
|
|
I hear you on the caution. I'm not feeling too great about messing with these but the boss want miracles and I'm running out of tricks so I guess I'm desperate to try this as I'm sure to screw up manually changing stuff back and forth for every release. changing a single define is so much easier in the long run.
I went ahead and put all my custom preprocessor symbol definitions in a stdafx2.h file and reference it from the top of the stdafx.h and the .rc2 file. This appears to have done the trick.
I kicked it a few times and my Resource symbols (including the "readonly" Afx... ones are showing being used by string tables so I'm guessing "she might hold together captain".
I'll probably regret this later but I'm game to try it out and see. 
Thanks again for all the advice.
|
|
|
|
|
bob16972 wrote: Thanks again for all the advice.
Happy to help, good luck!
|
|
|
|
|
You can also have the symbol defined as part of the project's settings as part of the command line. Since it sounds like you have different solutions, building different targets, but using a lot of common source files, this might provide more convenient. 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
Thanks for the ideas. This was already a single solution with a single project, that compiled into two different apps based on preprocessor symbols. Now it needs to have two identities for each so this might get interesting. Boy what a mess.
(I posted the approach I'm going to try in a different thread for this post)
Thanks again for taking some time out to help!
|
|
|
|
|
Not sure what version of VS you are using, but in VS2005 you could:
- extract the particular strings to a separate string table
- in VS, highlight the string table in Resource View, right click and show properties
- in the Condition field you can specify some preprocessor define - e.g BUILD1, this should now be added to the name of the string table
- right click on the string table and Insert Copy, and add your new condition on the copy - e.g. BUILD2
- create multiple builds of the project, and set the preprocessor defines in Project Properties / Resources / General
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
Thanks for the idea as it sounds a bit more elegant. I'm using VS 2003 and unfortunately if I try and create a second string table it reads...
"There cannot be more than one instance of this type. The instance of this object already created will be opened."
I've tried to add a string table at various nodes of the resource tree but I get the same error.
I'll keep your idea in mind when(if) I migrate this project to VS 2008 (we skipped 2005).
thanks for the tip.
|
|
|
|
|
We've been using this since VC6 to have customised menus, dialogs, bitmaps etc in different builds.
I just checked VC6 and it appears that in VC6 you can add a preprocessor condition to any resource item EXCEPT string tables, these seem to only depend on language. We skipped VS2003 so I can't comment on what you can do there, but if there is no Condition field in the Properties window on string tables then I guess it isn't supported yet. Just look at the properties windows for other resources (e.g. menus) and you should see the Condition field.
You should be able to use the same syntax in the .rc file that VS uses for other resources dependent on preprocessor definitions, and use the same in string tables. For example, a menu that is only included when DEFINE1 is defined appears as:
#if defined(APSTUDIO_INVOKED) || defined(DEFINE1)
#if defined(APSTUDIO_INVOKED)
IDR_MENU1$(DEFINE1) MENU DISCARDABLE
#else
IDR_MENU1 MENU DISCARDABLE
#endif
BEGIN
POPUP "Menu1"
BEGIN
MENUITEM "Help", ID_HELP_X
...
...
END
END
#endif
I'm not sure about the APSTUDIO_INVOKED, it seems to use two different mechanisms for the conditional inclusion, one for the IDE and the other for a command line version.
You should be able to create a couple of conditional menus or other resources and check the syntax of the .rc file.
Don't forget that you specify these defines under the Resources settings in the Project settings.
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
Hi ,
Is it possible to stop a running .exe and resume it later . After googling I came to know that every .exe is isolated from any other .exe. I am creating an application which will act like a 'BreakPoint setter' for second .exe .
Is it possible to stop execution of exe and its threads from another .exe.
Thanks
|
|
|
|
|
Hi,
I am not sure this is possible, but If you do so, I think there will be a possibility for deadlock.
Nitheesh George
http://www.simpletools.co.in
|
|
|
|
|
Both the .exe file will be created under one parent application. One is a UI process and another is worker exe
UI will try to add some break point and on the 'Click' event the another .exe will stop/resume its execution. So I cannt see any possiblity for deadlock. Correct me if I am not clear to explain
|
|
|
|
|
pandit84 wrote: One is a UI process and another is worker exe
Why a worker executable? What's wrong with a worker thread? That way, you consume less resources AND can get the job to be done faster!
Just use a worker thread, and one of the many thread synchronisation mechanisms like Critical section, mutex, etc. It could be as simple as a volatile variable, or could be as complex as a semaphore or having to use a pool of threads. Read up on thread synchronization, and use whichever synchronisation mechanism that suits your need.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
I totally agree with Rajesh, and I would like to point you to this great article[^]. It will really help you understand how to work with threads.
|
|
|
|
|
You need some form of Inter-Process Communication to do that, see, for instance, Interprocess Communications[^] at MSDN.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
The another .exe which is my worker exe will be running on a third party RTOS . Using synchronization it is possible within Win32 and RTOS process. My requirement docs says to stop a RTOS process from UI with a button click and resume it again with same button click (like a toggle) . Things will get more complex if synchronization is used because I am having ~32 threads on RTOS running. ...
Thanks a lot for your nice reply
|
|
|
|
|
pandit84 wrote: The another .exe which is my worker exe will be running on a third party RTOS . Using synchronization it is possible within Win32 and RTOS process. My requirement docs says to stop a RTOS process from UI with a button click and resume it again with same button click (like a toggle) . Things will get more complex if synchronization is used because I am having ~32 threads on RTOS running
What RTOS?! And 32 Threads running on an embedded OS?
You did not give enough information in your first post. See How to ask a question[^], and edit your question to include all relevant information for someone to give you an appropriate response that may be of help.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
I appologies. I thought it like a normal programming scenerio.
My application is actually a industrial software UI application with host 32 threads for a motion controller like a industrial robotics arms.
|
|
|
|
|
So, give the following information:
- Which operating system does your code run on? [Note: This particular board deals primarily with Windows, and may be flavours of UNIX. Other platforms can be supported as long as you're not doing anything propreitary to the OS, because people just may not know about it].
- Are all the 32 threads are running in the context of the same process? If so, just use a thread synchronisation mechanism.
- And what is this "other exe" you're talking about?
Please read the points mentioned in the link I gave you in my earlier reply, and include ALL relevant information if you want someone to help you.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
1. User interface is a Win32 process which communicates with worker layer (running on RTX - RTOS) , using shared memory. UI will be running on windows OS and Worker Layer exe will be running on Interval Zero RTX (Ver 2011). Worker on RTX RTOS will further communicating with hardware ( Industrial firmware components ) to control 32 motion controller devices.
> 32 Threads are in same context i.e. on worker layer side.
>"Other Exe" is nothing but RTX executable i.e worker exe.
Again I would like to say a big "THANKS"
|
|
|
|
|
What I would do is create a program 'work_cmd.exe' for your target platform that only handles the communication with your Win32 UI and nothing else. Your current worker.exe then should be demoted to a thread, and will be spawned from 'work_cmd.exe'. It will still be responsible for spawning the 32 sub-threads, but it needs explicit functions for the purpose of suspending or resuming those threads.
Your 'work_cmd.exe' can then just tell your worker thread to suspend it's dependend threads, and, upon completion, suspend the worker thread itself. To resume, it resumes your worker thread, and then tells it to resume its 'sub-threads'.
Note that my suggestion takes two commands to suspend or resume your threads, as 'work_cmd.exe' doesn't know about the additional threads and delegates their management to your worker thread. This assumes that the additional threads will not automatically be suspended with their parent. Maybe it's possible to spawn them in a way that forces them to be suspended whenever their parent is, but that might depend on your RTOS. (I'm not familiar with RTX)
Note, also, that 'work_cmd.exe' will have to keep running and listening for UI commands.
|
|
|
|
|
So the unique possibility for your GUI to pause/resume the worker thread is by setting a value into the shared memory (and the worker application must poll this value constantly.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
