|
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).
|
|
|
|
|
Maybe its best if I used as an example if I have the following text in my CrichEditctrl
D203 B11A 801C 0011A 0001C MVC FIELDA,FILEDB
and I however the mouse over FIELDB which has a value of X'00000003' I would like the tool tip control to display it much like the visual studio debugger
Hope this makes sense
thanks
|
|
|
|
|
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:
UpdateTipText
TrackPosition
TrackActivate
|
|
|
|
|
|
|
Using VS2019 (/std:c++20) and VS2022
I'm trying to formally document some code in header files.
Most of the time, adding comments does not seem to work properly in Intellisense.
What is the proper C++ comment format ?
This is mostly used to generate offline documentation (as far as I can see) and does not plays well with intellisense.
Seems sometimes intellisense breaks down and does not fully display or does not format the comments in the info tooltips.
For example :
sometimes this works or not:
struct ApplicationArguments {};
sometimes this works or not :
struct ApplicationArguments {};
I'm kind of baffled.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
That is the format I use and it seems to work fine. However, I have noticed with some of the system functions that a double slash works as well.
|
|
|
|
|
elephant me.
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:
- Fred.vcproj
- Fred.vcprog.LAPA.chg.user
- Fred.vcprog.LAPB.chg.user
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.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
modified 21-Aug-22 14:59pm.
|
|
|
|
|
With the disclaimer that I couldn't possibly try my suggestion on VC2008 (got rid of it long time ago) here is how I handle a similar issue.
- Keep everything under Git source control
- Add *.user to .gitignore
- Have everything setup once the way you like it on LAPA and LAPB.
Now every time you want to transfer from LAPA to LAPB you do git push on LAPA and git pull on LAPB. That keeps all *.user files the way you set them.
Mircea
|
|
|
|
|
Reasonable suggestion, but let's say I create a LAPC? Or I give the project to another developer?
He/she then run into the exact same issue.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
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.
Mircea
|
|
|
|
|
You would *think* that. Even though it's obvious what changed, I can set that and it still misbehaves. I'll keep digging.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Dusting this gripe off and putting it to bed.
For a certainty, VS2008 creates project files on a per system and person basis. It is what it is.
After multiple occurrences of having to slog through this nonsense, I finally came across the Import and Export Settings Wizard.
Go to Tools -> Import Export and follow the steps. I have yet to find any documentation from Microsoft that starts with "So, you're moving to a new machine..."
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Hi,
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);
return(0);
}
If I place a breakpoint on the Dlg_Proc preocedure, the program never goes there to start it:
BOOL CALLBACK Dlg_Proc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
chHANDLE_DLGMSG(hwnd, WM_INITDIALOG, Dlg_OnInitDialog);
chHANDLE_DLGMSG(hwnd, WM_SIZE, Dlg_OnSize);
}
return(FALSE);
}
Here is the resource for the dialog box:
IDD_DIRWALK DIALOG DISCARDABLE 10, 18, 250, 250
STYLE WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_POPUP|
WS_VISIBLE| WS_CAPTION | WS_SYSMENU |WS_THICKFRAME
CAPTION "Directory Walk"
FONT 8, "System"
BEGIN
LISTBOX IDC_TREE,0,0,0,0,NOT LBS_NOTIFY |
LBX_NOINTEGRAL_HEIGHT | NOT WS_BORDER |
WS_VSCROLL | WS_HSCROLL | WS_GROUP |
WS_TABSTOP
END
Here is the macro definition for messages:
#define chHANDLE_DLGMSG(hWnd, message, fn) \
case (message): \
return (SetDlgMsgResult(hwnd, uMsg, HANDLE_##message((hwnd), (wParam), (lParam), (fn))))
I don't think that the problem could be on the resource code for dialog box as long as the program even don't execute de
dialog box procedure.
If you know where the problem could be, please help me.
Thank you,
modified 23-Aug-22 12:32pm.
|
|
|
|
|
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)
{
RECT rc;
chSETDLGICONS(hwnd, IDI_DIRWALK, IDI_DIRWALK);
GetClientRect(hwnd, &rc);
SetWindowPos(GetDlgItem(hwnd, IDC_TREE), NULL, 0, 0, rc.right, rc.bottom, SWP_NOZORDER);
return(TRUE);
}
And the macro for chSETDLGICONS(hwnd, IDI_DIRWALK, IDI_DIRWALK);  is:
<pre lang="C++">
#define chINITSTRUCT(structure, fInitSize) \
(ZeroMemory(&(structure), sizeof(structure)), \
fInitSize ? (*(int*) &(structure) = sizeof(structure)) : 0)
#define chSETDLGICONS(hwnd, idiLarge, idiSmall) \
{ \
OSVERSIONINFO VerInfo; \
chINITSTRUCT(VerInfo, TRUE); \
GetVersionEx(&VerInfo); \
if ((VerInfo.dwPlatformId == VER_PLATFORM_WIN32_NT) && \
(VerInfo.dwMajorVersion <=3 && \
VerInfo.dwMinorVersion <= 51)) \
{ \
SetClassLong(hwnd, GCL_HICON, (LONG) \
LoadIcon(GetWindowInstance(hwnd), \
MAKEINTRESOURCE(idiLarge))); \
} \
else \
{ \
SendMessage(hwnd, WM_SETICON, TRUE, (LPARAM) \
LoadIcon(GetWindowInstance(hwnd), \
MAKEINTRESOURCE(idiLarge))); \
SendMessage(hwnd, WM_SETICON, FALSE, (LPARAM) \
LoadIcon(GetWindowInstance(hwnd), \
MAKEINTRESOURCE(idiSmall))); \
} \
}
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.
Thank you 
|
|
|
|
|
coco243 wrote: But the program dosen't reach the Dlg_OnInitDialog, I placed a breakpoint there.
Where is the code for chHANDLE_DLGMSG? I keep telling you to get rid of these ridiculous #define statements; they are just making it more difficult to see what is happening.
|
|
|
|
|
Here it is the code: ( it was in the first post too, I will modify de macros )
#define chHANDLE_DLGMSG(hWnd, message, fn) \
case (message): \
return (SetDlgMsgResult(hwnd, uMsg, HANDLE_##message((hwnd), (wParam), (lParam), (fn))))
Thank you,
modified 19-Aug-22 8:13am.
|
|
|
|
|
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(
HWND hDlg,
UINT uMessage,
WPARAM wParam,
LPARAM lParam
)
{
switch (uMessage)
{
case WM_INITDIALOG:
return OnInitDialog(hDlg, (HWND)wParam, lParam);
case WM_COMMAND:
return OnCommand(hDlg, LOWORD(wParam), (HWND)lParam, HIWORD(wParam));
}
return false; }
|
|
|
|
|
I changed the Dlg_Proc as you have said to me.
But my problem is that the program doesn't reach to the DlgProc function to be called.
I don't know why, what to do? but DialogBox function from WinMain doesn't call DlgProc. I think that here is the problem.
When I play the program it doesn't do any thing. Just execute, nothing displaied, and that's it.
|
|
|
|
|
So:
.cpp file
#include <windows.h> // tipul BOOL este definit in windows.h
#include "resource.h"
#include "WindowsX.h"
BOOL Dlg_OnInitDialog (HWND hwnd, HWND hwndFocus, LPARAM lParam)
{
RECT rc;
SendMessage(hwnd, WM_SETICON, TRUE, (LPARAM)LoadIcon(GetWindowInstance(hwnd),MAKEINTRESOURCE(IDI_DIRWALK)));
SendMessage(hwnd, WM_SETICON, FALSE, (LPARAM)LoadIcon(GetWindowInstance(hwnd),MAKEINTRESOURCE(IDI_DIRWALK)));
GetClientRect(hwnd, &rc);
SetWindowPos(GetDlgItem(hwnd, IDC_TREE), NULL, 0, 0, rc.right, rc.bottom, SWP_NOZORDER);
return(TRUE);
}
void Dlg_OnSize ( HWND hwnd, UINT state, int cx, int cy)
{
SetWindowPos(GetDlgItem(hwnd, IDC_TREE), NULL, 0, 0, cx, cy, SWP_NOZORDER);
}
INT_PTR CALLBACK Dlg_Proc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_INITDIALOG:
SetDlgMsgResult(hwnd, uMsg, HANDLE_WM_INITDIALOG(hwnd, wParam, lParam, Dlg_OnInitDialog));
break;
}
return(FALSE);
}
int WINAPI WinMain(HINSTANCE hinstExe, HINSTANCE hinstPrev, LPSTR pszCmdLine, int nCmdShow)
{
DialogBox(hinstExe, MAKEINTRESOURCE(IDD_DIRWALK), NULL, Dlg_Proc);
return(0);
}
.rc file
#include "resource.h"
#define APSTUDIO_READONLY_SYMBOLS
#include "afxres.h"
#undef APSTUDIO_READONLY_SYMBOLS
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
LANGUAGE 9, 1
#ifdef APSTUDIO_INVOKED
IDI_DIRWALK ICON DISCARDABLE "DirWalk.Ico"
IDD_DIRWALK DIALOG DISCARDABLE 10, 18, 250, 250
STYLE WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_POPUP|
WS_VISIBLE| WS_CAPTION | WS_SYSMENU | WS_THICKFRAME | DS_MODALFRAME
CAPTION "Directory Walk"
FONT 8, "System"
BEGIN
LISTBOX IDC_TREE,0,0,0,0,NOT LBS_NOTIFY |
LBX_NOINTEGRAL_HEIGHT | NOT WS_BORDER |
WS_VSCROLL | WS_HSCROLL | WS_GROUP |
WS_TABSTOP
END
1 TEXTINCLUDE
BEGIN
"resource.h\0"
END
2 TEXTINCLUDE
BEGIN
"#include ""afxres.h""\r\n"
"\0"
END
3 TEXTINCLUDE
BEGIN
"\r\n"
"\0"
END
#endif // APSTUDIO_INVOKED
#endif // English (United States) resources
#ifndef APSTUDIO_INVOKED
#endif // not APSTUDIO_INVOKED
resource file:
#define IDI_DIRWALK 400
#define IDC_TREE 401
#define IDD_DIRWALK 402
#ifdef APSTUDIO_INVOKED
#ifndef APSTUDIO_READONLY_SYMBOLS
#define _APS_NEXT_RESOURCE_VALUE 101
#define _APS_NEXT_COMMAND_VALUE 40001
#define _APS_NEXT_CONTROL_VALUE 1001
#define _APS_NEXT_SYMED_VALUE 101
#endif
#endif
Why my dialog box isn't displayed?
|
|
|
|
|
In your Dlg_Proc() handler, all messages are returning FALSE. Handled messages should return TRUE.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Change this:
SetDlgMsgResult(hwnd, uMsg, HANDLE_WM_INITDIALOG(hwnd, wParam, lParam, Dlg_OnInitDialog));
to this
HANDLE_WM_INITDIALOG(hwnd, wParam, lParam, Dlg_OnInitDialog);
return TRUE;
You only need to set a dialog result when you exit for the last time. And unless you need the result in your calling code then it is best to do nothing.
I think this book is so far behind the times that it is teaching you the wrong things, and the wrong way to do things.
|
|
|
|
|
In my opinion I can change the content of the Dlg_Proc for infinite because I don't know why, the program just don't
get to that Function Procedure.
And I don't know why you are ignoring me when I am telling you that my DialogBox function from WinMain doesn't starts
the Dlg_Proc procedure never. Please explain me that because I don't understand. All I want to do for now is to see
that my program stops at a breakpoint on the Dlg_Proc.
Are VC project settings? This is all the code that I have. I am missing something? Just please explain me why the DialogBox
doesn't starts its procedure.
I know to implplement dialog boxes, I have implemented a few, the problem in this topic is that I can't aproach this kind of message handling procedure. And I am sorry if I repeat myself and you try to explain me and I am not able to understand but... "Why the DialogBox from WinMain doesn't start the Dlg_Proc afferent procedure?"
Thank you,
modified 19-Aug-22 11:27am.
|
|
|
|
|
The DialogBox does start, but because your code is invalid it terminates (almost) immediately. I have changed your DialogProc to the following just to make it work:
INT_PTR CALLBACK Dlg_Proc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_INITDIALOG:
HANDLE_WM_INITDIALOG(hwnd, wParam, lParam, Dlg_OnInitDialog);
break;
case WM_COMMAND:
if (LOWORD(wParam) == IDCANCEL)
{
EndDialog(hwnd, IDCANCEL);
break;
}
return FALSE;
default:
return FALSE;
}
return TRUE;
}
But that is just to get the dialog to start and be able to close it. To do anything useful would require a lot of rewriting, or better still, start clean with up to date code.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
