I have thread id and Process id of the a application, now i want to get the main window handle of the application.
I know there is EnumThreadWindows function which can achive the same, but i am not sure how to use it and also i want to store the window handle after the call to EnumThreadWindows function, I have seens lot of samples which basically send event notification to the callback function for EnumThreadWindows which i don't want to do.
I want to launch a perl script as the pre-build step with Visual C++ .NET 7.1.
But the paths to the different EXE files I want to use in this script are not known, even if they are in the PATH environment variable. If I launch my script by hand, and not by Visual C++, it works well.
After many trials, it seems that the paths memorised in PATH are not known in the context of the pre-build command line.
Is there a way to remedy to that?
Thanks in advance
In our tests a simple pre-build step like "perl -v" is working with no problem, i.e. the perl application is found according to PATH environment variable. It is difficult to reproduce your problem. Maybe you should show us your pre-build command?
Thanks for answering.
Here is the non-working command line: perl.exe ..\create-getrevision.pl
Here is the working command line: C:\Perl\bin\perl.exe ..\create-getrevision.pl
This command is entered in the Project Properties dialog box, build results/before the build. These terms are maybe not the right translation of my german version of Visual C++... C:\Perl\bin is in the PATH of the system variables part on my Windows XP.
For the non-working case, I get the following error message: The command "perl.exe" is either not correctly written or cannot be found.
MSDN documentation for CreateFile function says that in Windows Me/98/95 "the file system restricts CreateFile to creating or opening files. You cannot create or open the [other] objects [...]". Therefore it seems you cannot open a volume in Windows 98.
I think you have to search for other approach for your problem. Maybe you should explain it here; perhaps it can be solved with other functions.
It doesn't give you the complete solution, since there are no logical sector to physical sector conversion, but you can make one yourself, using the information from the IO call IOCTL_DISK_GET_DRIVE_GEOMETRY
You cannot call non-static member functions inside a static function. The reason is simple: static function don't 'belong' to a particular instance of the class (they don't receive the this parameter), thus, you can only access members (functions and variables) that doesn't belong to a particular instance also (so only static members).
The solution to remove the static but I don't think this will solve the problem. In general, there is a way to explicitely pass the this parameter so that the function can use this parameter and call a public function from that particular instance.
Should work just fine. Never be afraid to go old-school instead of jumping through so many hoops just to use MFC's version of something.
-=- JamesIf you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! DeleteFXPFiles & CheckFavorites (Please rate this post!)
Nope. You are returning the address of a temporary string. Thus, the memory is not protected anymore. Sure, the pointers still 'points' at a the same address but the contents are not protected anymore, thus they can be overwritten.