|
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]
|
|
|
|
|
If the other application is running as a Windows service, then the "monitor" application can send a SCM pause command to the Windows service.
|
|
|
|
|
Thanks alot to all . I will try to implement all suggestions.
|
|
|
|
|
Hello everybody !
I wan't to save the bitmap to convert to a single color bitmap (8 pixel / Byte).
I use this way to save to 16 color bitmap. how to convert it to single bitmap ,or how to save it from the device context first ?
HBITMAP GetWindowBitmap(HWND hwnd, LPRECT lpRect)
{
if( !lpRect )
return NULL;
HDC hDC;
HDC hMemDC;
HBITMAP hBitmap = NULL;
HBITMAP hOldBitmap;
if( hwnd == NULL )
hDC = ::GetDC(HWND_DESKTOP);
else
hDC = ::GetWindowDC(hwnd);
if( hDC == NULL )
return NULL;
hMemDC = CreateCompatibleDC(hDC);
hBitmap = CreateCompatibleBitmap(hDC, lpRect->right - lpRect->left,
lpRect->bottom - lpRect->top);
if( hBitmap == NULL)
return NULL;
hOldBitmap = (HBITMAP)SelectObject(hMemDC, hBitmap);
BitBlt(hMemDC, 0, 0, lpRect->right - lpRect->left,
lpRect->bottom - lpRect->top, hDC, lpRect->left, lpRect->top, SRCCOPY);
SelectObject(hMemDC, hOldBitmap);
DeleteDC(hMemDC);
::ReleaseDC(hwnd, hDC);
return hBitmap;
}
BOOL SaveBitmapToFile(CString strFilePath,HBITMAP hBitmap)
{
HDC hdc = NULL;
FILE* fp = NULL;
LPVOID pBuf = NULL;
BITMAPINFO bmpInfo;
BITMAPFILEHEADER bmpFileHeader;
do{
hdc = ::GetDC(NULL);
ZeroMemory(&bmpInfo,sizeof(BITMAPINFO));
bmpInfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
GetDIBits(hdc,hBitmap,0,0,NULL,&bmpInfo,DIB_RGB_COLORS);
bmpInfo.bmiHeader.biBitCount = 0x10;
if(bmpInfo.bmiHeader.biSizeImage <= 0)
bmpInfo.bmiHeader.biSizeImage = bmpInfo.bmiHeader.biWidth*abs(bmpInfo.bmiHeader.biHeight)*(bmpInfo.bmiHeader.biBitCount+7)/8;
if((pBuf = malloc(bmpInfo.bmiHeader.biSizeImage)) == NULL)
{
::MessageBox(NULL,_T("Unable to Allocate Bitmap Memory"),_T("Error"),MB_OK|MB_ICONERROR);
return FALSE;
}
bmpInfo.bmiHeader.biCompression = BI_RGB;
GetDIBits(hdc,hBitmap,0,bmpInfo.bmiHeader.biHeight,pBuf,&bmpInfo,DIB_RGB_COLORS);
TRACE(_T("%s\r\n"),strFilePath);
if((fp=fopen(strFilePath.GetBuffer(strFilePath.GetLength()),"wb"))==NULL)
{
::MessageBox(NULL,_T("Unable to Create Bitmap File"),_T("Error"),MB_OK|MB_ICONERROR);
return FALSE;
}
bmpFileHeader.bfReserved1 = 0;
bmpFileHeader.bfReserved2 = 0;
bmpFileHeader.bfSize = sizeof(BITMAPFILEHEADER)+sizeof(BITMAPINFOHEADER)+bmpInfo.bmiHeader.biSizeImage;
bmpFileHeader.bfType = 'MB';
bmpFileHeader.bfOffBits = sizeof(BITMAPFILEHEADER)+sizeof(BITMAPINFOHEADER);
fwrite(&bmpFileHeader,sizeof(BITMAPFILEHEADER),1,fp);
fwrite(&bmpInfo.bmiHeader,sizeof(BITMAPINFOHEADER),1,fp);
fwrite(pBuf,bmpInfo.bmiHeader.biSizeImage,1,fp);
}while(false);
if(hdc)
::ReleaseDC(NULL,hdc);
if(pBuf)
free(pBuf);
if(fp)
fclose(fp);
return TRUE;
}<pre>
Thanks for your reply !
Best regards~~~
|
|
|
|
|
You can do it by following way.
First, you need storage space for color table as being palette entries.
typedef struct tagBITMAPINFO_8BPP
{
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[256];
} BITMAPINFO_8BPP;
I've used above structure for simplicity. You can also allocate it dynamically as much (sizeof(BITMAPINFO) + sizeof(RGBQUAD) * 255) in bytes. In that case, you need to adjust values in BITMAPFILEHEADER and file write operation accordingly.
...
LPVOID pBuf = NULL;
BITMAPINFO_8BPP bmpInfo;
BITMAPFILEHEADER bmpFileHeader;
...
bmpInfo.bmiHeader.biBitCount = 0x08;
...
bmpInfo.bmiHeader.biCompression = BI_RGB;
GetDIBits(hdc, hBitmap, 0, bmpInfo.bmiHeader.biHeight,
pBuf, (BITMAPINFO*)&bmpInfo, DIB_RGB_COLORS);
...
bmpFileHeader.bfReserved1 = 0;
bmpFileHeader.bfReserved2 = 0;
bmpFileHeader.bfSize = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFO_8BPP) +
bmpInfo.bmiHeader.biSizeImage;
bmpFileHeader.bfType = 'MB';
bmpFileHeader.bfOffBits = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFO_8BPP);
fwrite(&bmpFileHeader, sizeof(BITMAPFILEHEADER), 1, fp);
fwrite(&bmpInfo.bmiHeader, sizeof(BITMAPINFO_8BPP), 1, fp);
fwrite(pBuf, bmpInfo.bmiHeader.biSizeImage, 1, fp);
...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
