What about using some API calls to find the hWnd of the textbox in Window2. Take a look at: - FindWindow - GetDlgItem Use it somewhat as follows: HWND hMainWindow = FindWindow("[ClassName of main window]", NULL); if(hMainWindow != NULL) { HWND hTextbox = GetDlgItem(hMainWindow, [ID of the textbox]); ... } You can find out the classname of the main window and the ID of the textbox using Greatis Windowse (google on it, I don't have the link just like that). Once you figured out the hWnd of the textbox, you can use SetWindowText or a SendMessage WM_SETTEXT to put the text in the box in dialog 2. Another option might be SetDlgItemText, but then you can't check the hTextBox hWnd to be valid or not before sending. Good luck! - Fahr

Hello all, I'm having the following problem and can't figure out what's wrong: the application I'm working on has a View class to print. When I call the OnPrintPreview, it gives a nice preview screen, nothing wrong. When I call the OnPrint, it prints, no problems. However, when I press the 'Print' button in the Preview, it does nothing; it just closes. No printer dialog, no error, nothing. I find this very strange, obviously the printing code is ok, since it DOES print and it DOES preview. It only doesn't print from the preview screen... Anyone got a suggestion? Thanks, - Fahr

eh, sorry, forgot to reply... it all worked out fine :) Mem leaks found and resolved, thanks a lot for the tip! :)

Ok, I will try this when I'm back at work tomorrow :) Thanks a lot for the info, I'll let you know how it ended :) - Fahr

I guess just adding them to the workspace will do the trick, no? If not, then please tell me :) - Fahr

No, they're not dependencies. We have multiple actual programs which use the same shared DLLs, so the DLLs are mostly standalone projects alltogether. You think I can trace the leaks when I include the DLLs in question in the workspace of my project?

Yes, I have done it all. The point is that I DO see a HUGE list of memory leaks, I have a slight idea from which DLL and even class they come, but it wont give out any source files and/or lines. Only dumps objects...

I have access to the source of all the DLLs. And like I said; it does NOT state the origin of the memory leaks, it must be one of the DLLs, but I can't figure out which one. Please remember the title of that program! :)

Hello all, I am having some troubles with tracing memory leaks in VC++ 6. I have a program which includes a bunch of DLLs, now when I execute it and shut it, it dumps quite a bit of garbage from memory. Usually it states where the object was created, but in this case it doesn't, it only dumps objects. This leads me to believe that the memory leak is generated in one of the linked DLLs. Is there any trick or program which can figure out where the memory leak comes from? I have no idea where it originates and I'd like to clean it up... Thanks, - Fahr

Hello all, I just built a small program to log SMB connects. Using NetFileEnum I can pretty much log which user opens which directories and which files. But now I want to link this information to the host PC of the user. I can get all the users with their PCs using NetSessionEnum, but I can't link both. Situation; I have a public account on a big network, called LAN. Now with the thing I built I can see which files and dirs are opened by user LAN, yet I can't see from which PC it comes. And user LAN can be logged in from loads of PCs at the same time. I can use NetSessionEnum to get the PCs, but then I can't link it to the files they opened. Does anyone have any idea how I can get this information full? Thanks, - Fahr

Hello people, I am trying to catch the WM_COMMAND message of a certain button in an external application. Catching works fine with both WH_CALLWNDPROC and WH_CALLWNDPROCRET hooks. But after the catch I want to WM_NULL it, so the app wont actually execute the function that the button calls. After some browsing through the MSDN, it seems like the WH_GETMESSAGE hook is the only one that can actually modify messages. However, changing my WH_CALLWNDPROC hook to a WH_GETMESSAGE hook resulted in nothing. It seems as if WM_COMMAND never gets processed by WH_GETMESSAGE. It may be that WH_GETMESSAGE is the wrong hook to catch WM_COMMAND, but then how SHOULD I do it? WH_CALLWNDPROC can't modify the message, only inspect it... Thanks, - Fahr

Hello, I'm struggling with the following problem; at my job here, we use a database of texts for easy translation in our apps. Inside the source, we put IDs, which look like this: CString tmp = pLang->String(1005); for instance. Now, this is impossible to read and inconvenient when editing someone else's source. My idea was to create something that would show a tooltip with the actual text when moving the cursor over the ID. I tried to build a hook working with EM_CHARFROMPOS, EM_LINELENGTH and EM_GETLINE, to then feed it to a regexp and filter out the IDs. Problem is, the VC++ 6 source editbox reacts to none of these messages. I tried WM_GETTEXT, also no go. My next try will be to create an actual VC++ 6 addin, but I have NO idea where to start. And before I spend another few hours for nothing, I would first like to know if it's even POSSIBLE to create an addin that would generate a tooltip on mouseover. If anyone has an idea, I'd be glad to hear it. Thanks, - Fahr

yeah, I changed all it around... problem is tho, as soon as I change UNICODE,_UNICODE to _MBCS, I get about 5 unresolved externals... I'm using the DLL for native coding with Unreal Script, the script can call to the DLL and uses the core and engine of the game for game-specific functions, apperently those only support unicode... Which is terribly odd, cuz the game runs on ANY windows... - Fahr

Well, that article does shed light on a lot of issues, thanks a lot :) I actually DO need the DLL to run under Windows 98, if I use only unicode it wont work then I guess? I didn't quite realise that... So what do I do now? Change all my L""s back to _T("")s and all my WCHAR*s to TCHAR*s? Will that do the trick? And do I need to build 2 different DLLs for WinNT and Win9x?? - Fahr

OK! That worked! Thanks a lot :) It saves a lot of trouble of getting it myself, plus the weird trailing char error is no longer there :) Also, you suggested the use of L"", while I use _T(""), a quick look in the TCHAR.h gave me the idea that _T("") is defined as L""... So what IS the actual difference? If any... - Fahr

PathFindExtension results in: error LNK2001: unresolved external symbol __imp__PathFindExtensionW@4 I DO have shlwapi.h in my includes... - Fahr

Ok, since I'm compiling only unicode I stuck with the wcs commands (Unicode is required for this, I'm not ever going to recompile it in MBCS). If there's a good reason for me to use the _TCHAR and _tcs commands instead, please tell me :) The code DOES work now with the compare calls and the not writing back after uppercasing, but the 1-letter-extension problem still remains for some reason, after a one-letter extension it adds a 135-char... I don't get why... As for the delete[]s, what to do in such a case if I want to RETURN the FileExt? I can't delete it before the return. And also, what to do with static variables? I assume I can't delete those either... Thanks, - 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

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