|
DOUGH! I got it...seems in my attempt at this I left the button definition where it was...later in the program!
That coffee really works!
Thanks for looking
|
|
|
|
|
SetDlgItemText(....)
try.
|
|
|
|
|
hi,
I am using a system wide hook and get the handle (HWND) of the process about to start. How do I get the filename from this handle?
i am running win98,nt,2000,xp
thanks
neil
|
|
|
|
|
If you have the window handle you can use GetWindowThreadProcessId to get the process id , then using PSAPI or ToolHelp lib you can get the file name.
|
|
|
|
|
I have vc++ .net and I have a project that has a single define for compiling certain code for U.S. users and other code for Canadian users.
What I want to do is build two releases at the same time from the same code with one being built with the define BUILDCANADA defined and the other not, but I don't want to have two separate projects.
I see lot's of info on doing simultaneous separate builds based on compiler settings etc, but nothing that shows if it's possible to do one build with a define set and another with it not set. I guess what the real question is, is can you set a DEFINE in the build options somewhere?
|
|
|
|
|
Go into the "Build" menu, click on "Configuration Manager", here you can make multible configurations.
Then you can go into th projects options, and define what you need for each configuration.
To build both projects in a single step, select "Batch Build..." in the "build" menu...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Hi Anders, thanks for replying. I know you can do that, but the critical thing is that I need to have a DEFINE set differently for the two builds, is that possible?
|
|
|
|
|
In "Configuration dialog|C/C++|Preproccesor", there is an option called "Preprocessor definitions" where you can define your BUILDCANADA or whatever you want.
--------
Dave
|
|
|
|
|
Perfect! Exactly what I was trying to find.
Thank you very much.
|
|
|
|
|
Hi, In my program (VC++, MFC, MDI ap), I need a function to delete a directory and all it's contained files and sub-directories. I'm currently using "system" to call the DOS program Deltree.exe. However, I'm sure that there should be a pure Windows method to do the same thing that would be much cleaner. Has anyone any suggestions ?
Doug
|
|
|
|
|
Try this:
BOOL DelTree(CString cstrPath)
{
BOOL bRetVal = FALSE;
CString cstrTemp = cstrPath;
CString cstrOldDir;
char buffer[MAX_PATH];
CFileFind cFind;
CString cstrFileName, cstrTempFile;
cstrFileName.Format("%s%s",cstrPath,"\\*.*");
if (cFind.FindFile(cstrFileName))
{
BOOL bFound = TRUE;
while (bFound)
{
bFound = cFind.FindNextFile();
if (cFind.IsDots())
continue;
else
{
cstrTempFile = cFind.GetFilePath();
bRetVal = DeleteFile(cstrTempFile);
if (!bRetVal) break;
}
}
}
cFind.Close();
if (bRetVal)
bRetVal = ::RemoveDirectory(cstrPath);
else
return bRetVal;
}
Jason Henderson start page ; articles
henderson is coming
henderson is an opponent's worst nightmare
* googlism *
|
|
|
|
|
Jason,
Your solution appears correct. However, I'd like to point out a small detail which caught my eye. Your function's signature is BOOL DelTree(CString cstrPath) . Your parameter is a CString value, rather than a constant CString reference, which would be more appropriate: BOOL DelTree(const CString& cstrPath) .
I just wanted to point this out to you and hope that you understand why it's usually much better to pass objects by const reference rather than by value. I realize that the CString class has a copy-on-write scheme which makes passing by value a lot less expensive than it otherwise be. But, passing by const reference is still the most efficient way to pass most objects requiring "by-value" semantics.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Thanks.
Actually, I took this code from a COM dll and modified it rather quickly. I really didn't look it over all that well.
Jason Henderson start page ; articles
henderson is coming
henderson is an opponent's worst nightmare
* googlism *
|
|
|
|
|
The only problem I see is that it is not recursive, so it will not work like deltree, deleting all sub-directories and their contents too.
|
|
|
|
|
Hey you're right. Good catch.
It would be easy to modify though.
Jason Henderson start page ; articles
henderson is coming
henderson is an opponent's worst nightmare
* googlism *
|
|
|
|
|
Jason gave you the clean solution. However, here's another one similar to your "system" one, except that it doesn't show the DOS window:
::WinExec("deltree blah", SW_HIDE);
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
But this way (and also the "system" call) relies on "deltree.exe" being present on the system. On my w2k I don't have "deltree.exe" so the app won't work. I think it's better to use Jasons way.
--
karl
|
|
|
|
|
Hi all you guys !!! Many thanks for all your input - I've taken all the points that you've raised, and, as my ap is only for private "consumption" can live with the WinExec solution - I just "hated" droping into a DOS window in the middle of a Windows program but now that I can hide it,I'm happy !!!
Doug
|
|
|
|
|
Hello,
I'm trying to use the API FindFirstFile in a non-MFC DLL using VC++ 6 and I get the following error on compile:
error C2664: 'FindFirstFileW' : cannot convert parameter 1 from 'const char *' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style
cast or function-style cast
On this line:
HANDLE Finding = FindFirstFile("C:\\*.*", &FindFileData);
Now I can be stupid, but I don't think that a pattern, which is described as an LPCSTR in the MSDN, would ask for an unsigned short*...
Can anybody tell me what I'm doing wrong here?
Thanks,
- Fahr
|
|
|
|
|
any chance you're doing a Unicode build?
-c
I'm not the droid you're looking for.
|
|
|
|
|
That why also my guess.
Have you tried
HANDLE Finding = FindFirstFile(_T("C:\\*.*"), &FindFileData); ?
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Well, that seems to work (could you maybe also explain WHY it works?)
Now I get an error on this:
FString temp = ANSI_TO_TCHAR(FindFileData.cFileName);
it seems to be related, too, the error reads;
error C2664: 'winGetSizeUNICODE' : cannot convert parameter 1 from 'unsigned short [260]' to 'const char *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
a _T() or L() doesn't work here tho :S
- Fahr
|
|
|
|
|
That's fixed, apparently the ANSI_TO_TCHAR was not needed cuz it's already unicode. My bad...
Tho I still don't get why it works like this or not...
- Fahr
|
|
|
|
|
That could very well be, how would I check that? I DID tweak a lot of the compler and linker settings...
How is that related anyways?
- Fahr
|
|
|
|
|
FindFirstFileW is the wide-char version of FindFirstFile. somehow, you've made the compiler think it needs be using this version instead of FindFirstFileA (the single-byte version).
I'm not the droid you're looking for.
|
|
|
|