|
ShellExecute or ShellExecuteEx
HINSTANCE ShellExecute(
HWND hwnd,
LPCTSTR lpOperation,
LPCTSTR lpFile,
LPCTSTR lpParameters,
LPCTSTR lpDirectory,
INT nShowCmd
);
-- or --
BOOL ShellExecuteEx(
LPSHELLEXECUTEINFO lpExecInfo
);
typedef struct _SHELLEXECUTEINFO{
DWORD cbSize;
ULONG fMask;
HWND hwnd;
LPCTSTR lpVerb;
LPCTSTR lpFile;
LPCTSTR lpParameters;
LPCTSTR lpDirectory;
int nShow;
HINSTANCE hInstApp;
// Optional members
LPVOID lpIDList;
LPCSTR lpClass;
HKEY hkeyClass;
DWORD dwHotKey;
union {
HANDLE hIcon;
HANDLE hMonitor;
};
HANDLE hProcess;
} SHELLEXECUTEINFO, *LPSHELLEXECUTEINFO;
That will do it
Sjoerd van Leent
LPCSTR Dutch = "Double Dutch "
|
|
|
|
|
but how?
for my dos based application, which takes 3 arguments,
<br />
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])<br />
is lpParameters will be the one i should set for my an argument?
what about int argc and the third parameter envp in main?
I dont' really understand because I have never call any applications from one applications.
thanks
|
|
|
|
|
This is how I had tried but it is not working!
the following code is in the dialog based application
<br />
void DialogBasedApp::OnTesting()<br />
{<br />
SHELLEXECUTEINFO lpExecInfo;<br />
const char* verb = "open";<br />
lpExecInfo.cbSize = sizeof(SHELLEXECUTEINFO);<br />
lpExecInfo.lpFile = "c:\\printExcel\\Debug\\printExcel.exe";<br />
lpExecInfo.fMask=SEE_MASK_DOENVSUBST|SEE_MASK_NOCLOSEPROCESS ; <br />
lpExecInfo.hwnd = NULL;<br />
lpExecInfo.lpVerb = verb; <br />
lpExecInfo.lpParameters = "c:\\testing.xls";<br />
lpExecInfo.lpDirectory = NULL;<br />
lpExecInfo.nShow = SW_SHOW ; <br />
lpExecInfo.hInstApp = (HINSTANCE) SE_ERR_DDEFAIL ;
ShellExecuteEx(&lpExecInfo); <br />
if(lpExecInfo.hProcess != NULL)<br />
{<br />
::WaitForSingleObject(lpExecInfo.hProcess, INFINITE);<br />
::CloseHandle(lpExecInfo.hProcess);<br />
}<br />
MessageBox("Finished Printing Excel");<br />
}<br />
my dos based application, which is called printExcel.cpp, is right below
<br />
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])<br />
{ <br />
AfxMessageBox(argv[0]);<br />
return 1;<br />
<br />
}<br />
Honestly, i don't even know how to get the argument so no doubt that i have no idea where the program got wrong.
can you tell me what and where it got wrong and how to fix it, please.
|
|
|
|
|
Hi Win,
In this line:
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
is actually all you need. The 'argc' is the number of items specified on the commandline.
The array argv are all commandline arguments (including the name of the executable itself, printExcel.exe).
You can retrieve every argument by just using the index in the array:
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
CString strArgument;
for (int i = 0; i < argc; i++)
strArgument = argv[i];
} // Not compiled, assuming it's correct
--
Alex Marbus
www.marbus.net
But then again, I could be wrong.
|
|
|
|
|
I see two odd things here.
First, how can you call AfxMessageBox in a DOS-based app ? If it is really a DOS app then shouldn't you use printf ? You can add a getch() to see what the console window says before it closes.
FWIW, argv[0] will be the name of the executable always, regardless of what args are passed.
argv[1] will be the first passed argument and argc will tell you how many were passed. I think this has been said already but I will reiterate. Here is a loop to print out all passed args except for the exe's name (which is why we start at 1) :
for( int index = 1; index < argc; index += 1 )
fprintf( stdout, "arg %d is '%s'\n", index, argv[index] );
Second is a stylistic issue. You appear to be using Hungarian notation. Well, lp stands for long pointer and you have an instance of the structure so it is not a pointer.
|
|
|
|
|
oh yeah.. my dos based application support MFC therefore i can call AfxMessageBox(). you know when you build the project, in first step, you choose win32 console application and in step 2,
you choose hello world support MFC option instead of hello world and empty application.
for second question i can't explain coz i don't know what is Hungarian notation.. ^_^ no clue at all. what is it?
|
|
|
|
|
Do you need the extra params of ShellExecuteEx? Else, I would just use:
ShellExecute(hInstance, //handle of the executing program*/
"open", // open the program
"C:\\program.exe", //Windows register understands that this will be an executable
"/?", // you don't know how to use program.exe, so typing a question mark
NULL, // You can give up de directory, but is not necessary
SW_SHOWNORMAL // show the damned console window
);
LPCSTR Dutch = "Double Dutch "
|
|
|
|
|
Thanks.. but I need to pass an argument, which is going to be file name.
the dos based program is basically opening excel files and format it like setting pagesetup like all pages in landscape, scaling 70%, fixing the margins.. and so on.
the dialog based program, smpPrint, have files' names, including excel files. other files could be, .txt, .doc, .tif, etc. i want smpPrint to use the excelPrint, dos based program, will take a file name, and format it. that's what i want to do.
and i have to know when the user closed Microsoft Excel application, so i have to use shellexecutex. shellexecuteex have a parameter that can tell the application is closed .
|
|
|
|
|
i got it .. thank you all..
|
|
|
|
|
Is experimented with both on the heap and on the stact to pass a __stdcall (WNDPROC) to different functions. But the program (and explorer.exe!) crashes when I do so. Does anyone know how to safely pass a CALLBACK through a function.
eg:
WNDPROC xproc;
LRESULT CALLBACK WindowProc(...)
{
}
void a()
{
b((WNDPROC)WindowProc)
}
void b(WNDPROC wndproc)
{
// Do something like:
xproc = wndproc;
c();
}
void c()
{
SetWindowLong(hWnd, GWL_WNDPROC, (long)xproc);
}
Don't try this!
Thanks in advance,
Sjoerd van Leent
LPCSTR Dutch = "Double Dutch "
|
|
|
|
|
There are a couple of issues in your code (maybe they are due to the fact that you have deleted some stuff in your post):- The right signature for
WindowProc is
LRESULT CALLBACK WindowProc(HWND hwnd,UINT uMsg,WPARAM wParam,LPARAM lParam)
WindowProc should return a value. Also, typically you will forward most calls to DefWindowProc :
LRESULT CALLBACK WindowProc(HWND hwnd,UINT uMsg,WPARAM wParam,LPARAM lParam)
{
return DefWindowProc(hwnd,uMsg,wParam,lParam);
} Apart from this, the code seems just fine.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
That was indeed for easyness sake
Sjoerd
LPCSTR Dutch = "Double Dutch "
|
|
|
|
|
Guys:
I need to test the existence of a file on Novell server. I could use _access() function. But, under some conditions (example: when the Novell Server is in the process of shut-down), the _access() function takes very long time to return to the caller.
So, what I need is a scheme which will enable me testing the existence of a file asynchronously.
The Async version of access() should check the file existence and notify the caller once it is done with the file check.
Thanks in advance.
|
|
|
|
|
Try using CreateFile in FILE_FLAG_OVERLAPPED mode (this probably will work only in NT/2k/XP systems.)
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Not sure whether I should post this in the VC++ section or XML, but since I request code, VC++ seemed the best place to me.
I'm searching for a piece of sourcecode that will convert RTF data to XML. Preferrably plain C++, not using MFC or anything else. Any hints on how to do this would be just as great.
The goal is to save a piece of RTF formatted data between a single XML tag.
--
Alex Marbus
www.marbus.net
But then again, I could be wrong.
|
|
|
|
|
Hi Alex,
I've just downloaded and tried IRun RTF Converter 1.11. It comes with an utility program that seems to work just fine. Also, it provides a .DLL you can use in your apps (not exactly source code, but it's probably the next best thing.) The whole thing is freeware.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks Joaquín.
The main issue is that is really must be platform independent (thus, standard C++). However, I read on the website (http://www.pilotltd.com/irun/) that the sourcecode is available on request. I think I might contact them (unless somebody else knows a better solution?)
--
Alex Marbus
www.marbus.net
But then again, I could be wrong.
|
|
|
|
|
i want to execute an *.mdb file by my cpp program...
does anyone know how to do this???
thanx for all answers...
|
|
|
|
|
Ok, first of all *.mdb files are not executables!
But I think what you want to do is open the mdb file
in Access ?? Is that right ?
If so you can use
ShellExecute(..) ;
with lpOperation as "open".
|
|
|
|
|
Hi all,
I'm suffering a major resource leak on Win95/98/Me in one of my drawing routines.
I realise that before an object is destroyed one must ensure it is not selected in the device context by selecting the old object beforehand.
However where my knowledge is lacking is with the use of multiple pens:
For example suppose I have a red and a blue pen.
Currently I store the old pen when selecting the red.
I then use the red pen.
Next I select the blue pen, ignoring the returned pen.
After using the blue pen, before exiting I reselect the old pen (stored when selecting the red)
I then call DestroyObject for both the red and blue pens.
Is this sufficient or must I store the oldpen each time and restore it before selecting a new one? Surely not?!
This leak is driving me insane! I know the leak is in this function because if I remove the call no crash occurs. However I cannot for the life of me see the leak! I've tried using the example here on CP to Save and Restore the DC state before and after drawing, without success.
Thanks
--
The Obliterator
|
|
|
|
|
If you are using MFC, every thing is taken care of if all the
objects are local objects.
But if you are programming in SDK you need to make calls
to DeleteObject with the resource handle.
|
|
|
|
|
I'm using MFC - and all is definitely not taken care of!
Anyhow it looks like I've finally found the leak - I'll be testing on Win9x tomorrow to be sure!
There was a pen constructed inside an if statement then selected. The old pen should have been reselected before leaving the if statement. As it was not I'm guessing the pen could not be correctly destroyed as its scope was lost.
Thanks anyhow.
--
The Obliterator
|
|
|
|
|
|
Wouldn't you have thought it could assert in the destructor if selected in the DC???
--
The Obliterator
|
|
|
|
|
Check your knowledge on DC b4 replying..
Sudip
Stupidity Sucks
|
|
|
|