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