|
I think if you have the main function in your project, with arguments like this:
int main(int argc, char * argv[], .....)
then argv[0] points to the path of current executable.
In case of Windows applications, you can try the GetModuleFileName(NULL, .....) function.
|
|
|
|
|
Droze wrote: i am currently trying to make my program copy or move itself into my "programs to test " folder...use the shellexecute
How are you doing this? 
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
You could use the Win32 function GetModuleFileName with a NULL module handle.
Steve
|
|
|
|
|
I'm looking for a win32 call that will allow me to restore the browser window I'm using to display help if it's minimized. I do have a handle to the main window.
|
|
|
|
|
dan neely wrote: I do have a handle to the main window.
With such, call ShowWindow().
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
thanks. Is there also a call that can get the current window status? SW_RESTORE behaves properly if the window was minimized or visible but unmaximized (does nothing). Unfortunately, if the window is displayed maximized it will umaximize it.
|
|
|
|
|
dan neely wrote: Is there also a call that can get the current window status?
You mean like IsIconic() or IsZoomed()?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
You have to attach your window to the thread of the current process first:
How to steal focus on 2K/XP [^]
----------
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.
- Laurence J. Peters
|
|
|
|
|
I'll have to take a closer look at that. I've noticed SetForegroundWindow() occasionally failing for no reason I can understand, but am not sure if it's worth the effort needed to port it to my c# app.
|
|
|
|
|
I am relatively new to the Visual C++ IDE (using version 7). For console input programs which take command line arguments, where can I enter these arguments so that they get passed to my program when I am using the debugger?
Thanks.
|
|
|
|
|
In Properties dialog of your project, Debugging --> Command Arguments.
|
|
|
|
|
Project+Settings+Debug TAB :-third editbox(Program arguments)
Regards,
FarPointer
Blog:http://farpointer.blogspot.com/
|
|
|
|
|
I call a dll from am MFC app MyApp
From the dll I instantiate a CDialog like so
tests = new CTests(0);
I thought this would 'detach' the CDialog from the dll. Now after the dll has done its job, when I go to dismiss myApp, this CDialog vanishes too. I want to keep it around, but do want to get rid of MyApp. How do I manage this? I thougt for sure that putting the parent pointer as 0 would have done the trick....
sb
|
|
|
|
|
All that code executing the window in the DLL belongs to your MyApp process, so when the MyApp process is gone, so is the DLL and the dialog. You might be able to hide the window for the MyApp, and thus still have the window from the DLL visible and processing user inpout on the screen.
I've seen better runs in my shorts! - Patches O'Houlihan
|
|
|
|
|
From the design point of view, you need to understand these questions yourself:
Why do I want to keep the dialog when I terminate my app?
What is the purpose of the dialog, of the app?
After I terminate the app, what does my dialog do?
- It's easier to make than to correct a mistake.
|
|
|
|
|
The CDialog is an addon to an existing app. Ithas a progres bar on it, plus a histogram and the user wants to retain this window and be able to proceed further. Right now he can't proceed further if this app is not shut down.
|
|
|
|
|
You should make that dialog part of your app, instead of an addition. This way, your app will be cleaner and more robust.
That being said, if you insist, you could keep the dialog alive after you terminate the app. Follow these steps:
1) Write another little app2, which handles the dialog.
2) Spawn app2 from within app.
3) Terminate app.
This will no doubt create unnecessary complexities to your application.
- It's easier to make than to correct a mistake.
|
|
|
|
|
Good morning,
In a small sample test program, I change the background color of a dialog with OnCtlColor.
When running the application, the default MFC CButton button ( OK button ) is drawn like it is still on the default dialog background color, not what I have set in OnCtlColor.
Is it still allowable by Windows XP, without having to re-write, inherite and override everything, to have a "XP style" button on a non default background ?
Also, Is there a good description on Visual Style/Themes that I can have a look at ? I looked at MSDN, but it's not helping that much.
Thanks.
Max.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
i hav three dialog boxes
third dialog box contain menu
i want that when i goto third dialog box from first dialog box then its menu are disabled but when i go from second dialog box third dialog box menues are not disabled.
plz send me code how to do it
Please mail me
|
|
|
|
|
Which of the dialogs are modal and which are modeless?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Simple. Use a boolean flag, call it bRemoveMenu, and set it to false by default. Then when the dialog is launched from the third dialog box, call SetMenu(NULL). That will clear the menu from the dialog box, giving you a window without a menu. It's easier than traversing through the menu disabling each option.
|
|
|
|
|
Using the word "plz" just drips with sincerity. I so want to help people who use it. 
|
|
|
|
|
|
Try using :
CRect rc;
GetClientRect(&rc);
dc.FillSolidRect(&rc,RGB(255,128,162));
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
