I have some question about the class. I would like to use it on My CRichEditctrl where the source code is for my debugger.
There are CWnd members in a number of the methods in the class would that in my case be the CrichEditCtrl in Addition the HiTest api which has a CPoint member is that point relative to (in my case) the CRichEditCtrl
It depends upon what and how are you going to display tooltips for your control.
If it would be some text for the whole control then pass the CDialog CWnd* (in this case you will handle the TTN_NEEDTEXT notification in the dialog class).
If the tooltip text would depend on some position or some content within the controls then it could be better passing the control CWnd* (then you will handle the TTN_NEEDTEXT notification in the control's class).
Then you should create the tooltip control within your CrichEditctrl class passing the CrichEditctrl CWnd* as the parent.
Then you would have to implement some handling (the mouse move - ?) procedure to determine what text is to be displayed in tooltip. If the will be some (new!) text then use the following CToolTipCtrlmethods:
First, don't tell me to upgrade, for this project I'm stuck on VS2008 for an embedded project. From time to time, I need to move a development project to new hardware. Lets say I start on LAPA (laptop A) and I copy it to LAPB. When I open the project (we'll call it Fred and my user name is chg) on LAPB, I now have to user project files in the folder:
Now I can see VS loading fred.vcproj and then adding a specific user's settings - sort of - but I cannot come up with a good reason why the machine name would be included. In any event, on LAPB, I would expect to pick up those settings. Instead, I find that some of my project settings have changed:
- Deployment changes from the old setting to %CSIDL_PROGRAM_FILES%\fred.exe
- Debugging remote executable changes from the default to %CSIDL_PROGRAM_FILES%\fred\fred.exe
for ALL targets.
This would be a minor irritation if we were just talking about my example, but my actual application has over 80.
Comparing the user vcproj files, I see where the RemoteMachine has changed as well as the RemoteExecutable. But if I update these in the new LAPB project file, I still get %CSIDL_PROGRAM_FILES% inserted.
Any insight before I start slogging through this crap?
some of my deployment settings default to whatever MS deems appropriate.
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Newer versions of VS can run happily without *.user file. If it's missing it will be recreated with some reasonable defaults. So in your case if you go to LAPC you do a git pull and than, the first time, you will have to adjust the .user file to your liking. After that it will stay on that machine.
I am trying to compile a project who use message crackers and is different from those wich I am used with(those projects that uses WindProc procedure and the other functions automatically created by the VS IDE)
This is the windows main function where I call DialogBox function:
int WINAPI WinMain(HINSTANCE hinstExe, HINSTANCE hinstPrev, LPSTR pszCmdLine, int nCmdShow)
DialogBox(hinstExe, MAKEINTRESOURCE(IDD_DIRWALK), NULL, Dlg_Proc);
If I place a breakpoint on the Dlg_Proc preocedure, the program never goes there to start it:
I think you are missing the DS_MODALFRAME style from your dialog template. And your message handlers could contain anything - we cannot see the code. As I already suggested to you, get rid of these big defines and put the source in your handler. You will then at least have a chance of finding out what is wrong, as will we. And a better place to learn how to code for Dialogs is at About Dialog Boxes - Win32 apps | Microsoft Docs[^.
Thank you for your response, unfortunately not DS_MODALEFRAME is the problem
The problem is ( I think ), that when DialogBox function is called in WinMain, its associated procedure function Dlg_ProcDlg_Proc isn't executed.
Richard MacCutchan wrote:
And your message handlers could contain anything - we cannot see the code.
Are you reffering to Dlg_OnInitDialog as message handlers? It's code is:
BOOL Dlg_OnInitDialog (HWND hwnd, HWND hwndFocus, LPARAM lParam)
// Associate an icon with the dialog box.
chSETDLGICONS(hwnd, IDI_DIRWALK, IDI_DIRWALK);
// here is some code that I didn't got to, or have patience to write
SetWindowPos(GetDlgItem(hwnd, IDC_TREE), NULL, 0, 0, rc.right, rc.bottom, SWP_NOZORDER);
And the macro for chSETDLGICONS(hwnd, IDI_DIRWALK, IDI_DIRWALK); is:
#define chINITSTRUCT(structure, fInitSize) \
(ZeroMemory(&(structure), sizeof(structure)), \
fInitSize ? (*(int*) &(structure) = sizeof(structure)) : 0)
// Dialog Box Icon Setting Macro// The call to SetClassLong is for Windows NT 3.51 or less.// The WM_SETICON messages are for Windows NT 4.0 and Win 95#define chSETDLGICONS(hwnd, idiLarge, idiSmall) \
OSVERSIONINFO VerInfo; \
chINITSTRUCT(VerInfo, TRUE); \
if ((VerInfo.dwPlatformId == VER_PLATFORM_WIN32_NT) && \
(VerInfo.dwMajorVersion <=3 && \
VerInfo.dwMinorVersion <= 51)) \
SetClassLong(hwnd, GCL_HICON, (LONG) \
SendMessage(hwnd, WM_SETICON, TRUE, (LPARAM) \
SendMessage(hwnd, WM_SETICON, FALSE, (LPARAM) \
But the program dosen't reach the Dlg_OnInitDialog, I placed a breakpoint there.
What do I miss? If it is really necessary for the clearness of the code I wll add and the macros in code.
And guys please don't get upset on me because I insist to solve this old kind of program, but I am curious about this different style of managing windows messages and please help me to go through.
So you have a macro inside a macro which just makes it worse. I suggest you throw this code (and that book) away and write a proper inline handler. I have just tested your template and it loads the dialog and handles the WM_INITDIALOG message:
INT_PTR CALLBACK DlgProc(
return OnInitDialog(hDlg, (HWND)wParam, lParam); // calls the initialization function
return OnCommand(hDlg, LOWORD(wParam), (HWND)lParam, HIWORD(wParam)); // handles any button etc. messages
returnfalse; // default processing