|
I plan to use MFC DLL dynamically linked option. I have several utilities to distribute in one bundle...
diligent hands rule....
|
|
|
|
|
|
thank you! first to know VS 2015, VS 2017,and VS2019 have the same redistribute.
diligent hands rule....
|
|
|
|
|
Yes, this is the future direction going forward because MS does not want the user to install many VC++ redistributables on their machine.
|
|
|
|
|
your screenshots are very helpful. thanks.
diligent hands rule....
|
|
|
|
|
hi
I am trying to add a MENU bar to my Dialog when I look at this link seems I should be able to
DIALOG resource - Win32 apps | Microsoft Docs[^]
however after I add it
IDD_DIALOG21 DIALOGEX 0, 0, 790, 321
MENU IDR_MAINFRAME
STYLE DS_SETFONT | DS_MODALFRAME | DS_FIXEDSYS | WS_POPUP | WS_CAPTION | WS_SYSMENU
CAPTION "Dialog"
FONT 8, "MS Shell Dlg", 400, 0, 0x1
BEGIN
CONTROL "",IDC_RICHEDIT21,"RichEdit20A",ES_MULTILINE | WS_BORDER | WS_TABSTOP,27,7,780,273
LTEXT "Static",IDC_STATIC15,7,7,20,273,WS_CLIPSIBLINGS
END
and open up the dialog in the resource editor it doesn't display
I tried creating a new project "Dialog Based" and the menu (control to add it ) in the wizard was grayed out
thanks
|
|
|
|
|
I don't have a VS version that includes the resource editor, so I have to do things manually. However, I can confirm that dialog boxes work fine with menus.
|
|
|
|
|
ok maybe it only display them when you do a SHowWindow
|
|
|
|
|
I thought you were talking about a modal dialog.
|
|
|
|
|
Easy to do it manually .. inside WM_INITDIALOG assuming the dialog window handle is hWnd
Try this
HMENU hMenubar;
HMENU hMenu;
hMenubar = CreateMenu();
hMenu = CreateMenu();
AppendMenuW(hMenu, MF_STRING, 10000, "&New");
AppendMenuW(hMenu, MF_STRING, 10001, "&Open");
AppendMenuW(hMenu, MF_SEPARATOR, 0, NULL);
AppendMenuW(hMenu, MF_STRING, WM_QUIT, "&Quit");
AppendMenuW(hMenubar, MF_POPUP, (UINT_PTR)hMenu, "&File");
SetMenu(hWnd, hMenubar);
In vino veritas
|
|
|
|
|
|
ForNow wrote: after I add it
IDD_DIALOG21 DIALOGEX 0, 0, 790, 321
MENU IDR_MAINFRAME
...
END
and open up the dialog in the resource editor it doesn't display
Did you create the menu IDR_MAINFRAME itself?
|
|
|
|
|
IDR_MENU
is defined in my resource file I basically took the menu for the MainFrame and wanted to use it for the Dialog
Opening up The resource editor I am beginning to think when you view a dialog with menu it wont display it
There is a only a way to view the menu by itself
once I get my code going and do a ShowWindow for the Dialog i'll see if it displays the menu
IDR_MAINFRAME MENU
BEGIN
POPUP "&File"
BEGIN
MENUITEM "E&xit", ID_APP_EXIT
END
POPUP "&Edit"
BEGIN
MENUITEM "&Undo\tCtrl+Z", ID_EDIT_UNDO
MENUITEM SEPARATOR
MENUITEM "Cu&t\tCtrl+X", ID_EDIT_CUT
MENUITEM "&Copy\tCtrl+C", ID_EDIT_COPY
MENUITEM "&Paste\tCtrl+V", ID_EDIT_PASTE
END
POPUP "&View"
BEGIN
MENUITEM "&Toolbar", ID_VIEW_TOOLBAR
MENUITEM "&Status Bar", ID_VIEW_STATUS_BAR
END
POPUP "&ProgDebug"
BEGIN
MENUITEM "Program Debug", ID_DEBUG
END
POPUP "&Asidlist"
BEGIN
MENUITEM "Address Space List", ID_ASID
END
POPUP "&Help"
BEGIN
MENUITEM "&About DBGR...", ID_APP_ABOUT
END
END
|
|
|
|
|
I wanted to launch 'Caliberate the screen for Pen or touch input' (Tablet PC Settings) using Rundll32 Commands in Windows 10.
for ex like : rundll32.exe shell32.dll,Control_RunDLL tabletpc.cpl
Is anyone have an idea how to do it for this option. tabletpc.cpl option opening 'Pen and touch' window. I wanted to open Tablet PC Setting window not the Pen and Touch window.
|
|
|
|
|
|
Hello how to create a C++ application to send a HTTP request for Dialer.exe in Win32 using TSP ?
|
|
|
|
|
|
An attempt to learn and make sense of evaluating results.
Making these assumptions, right or wrong
"bool" is not "standard" C/C++ type
when "condition" such as in "if(condition)" evaluates to true , it is binary zero
thus if(condition == 0) would make better sense
then if(condition)
most "well written functions return x" , x being mostly zero when function is successful
when function fails – the return value is (generally) -1 or positive value identifying the error
then same as above - if(function (z) == 0) should prevail.
Of course explicit evaluation of result to zero could prevent hard to locate bugs when these commonly used implicit evaluation conventions are not followed by author of the code..
Any other views / comments would be appreciated.
|
|
|
|
|
Quote: "bool" is not "standard" C/C++ type
Well... Fundamental types - cppreference.com[^], Boolean type support library - cppreference.com[^].
Quote: thus if(condition == 0) would make better sense
then if(condition)
most "well written functions return x" , x being mostly zero when function is successful
when function fails – the return value is (generally) -1 or positive value identifying the error
then same as above - if(function (z) == 0) should prevail.
In C++ , if a function returns a bool then using
if ( function(x) ) is the only meaningful way I see.
On the other hand, if the function returns an integer data type, then
if (function(x) == expected_int_result) is the most sensible approach.
|
|
|
|
|
Hello,
perhaps there's a confusion with older versions of C language where bool was not a standard type.
But in all cases :
"when "condition" such as in "if(condition)" evaluates to true, it is binary zero" is false !
cppreference.com[^] : If the source type is bool, the value false is converted to zero and the value true is converted to the value one of the destination type (note that if the destination type is int, this is an integer promotion, not an integer conversion).
|
|
|
|
|
Vaclav_ wrote: most "well written functions return x" , x being mostly zero when function is successful Not necessarily; many functions return actual data rather than success/failure values. The decision on what to return depends on the requirements of the program.
And as Carlo points out below, bool is a fundamental type in C++.
|
|
|
|
|
Vaclav_ wrote: "bool" is not "standard" C/C++ type
It is not clear what "standard" do you mean.
According to wiki:
Initial implementations of the language C (1972) provided no Boolean type...
Standard C (since C99) provides a boolean type, called _Bool. By including the header stdbool.h, one can use the more intuitive name bool and the constants true and false.
C++ has a separate Boolean data type bool
So just check it out:
Boolean data type - Wikipedia
|
|
|
|
|
By "standard" I was referring to your definition of "1972 C language" which did not have "type" of bool.
As a side question
then where did the "true = 1 " and "false = 0 " convention came from ?
It seems that it is just the opposite true = 0 and false = 1 which is commonly in use , without actually referencing "true" or "false".
I have never seen
if(condition == true) , but if(condition) often assumes condition == 0 as true.
Of course "it depends on who coded the software" is obvious catch all.
|
|
|
|
|
Vaclav_ wrote: By "standard" I was referring to your definition of "1972 C language" which did not have "type" of bool.
My Goodness!!!!!
No wonder you are confused. NOBODY uses C72 except in DIRE circumstances. The only time I've used C72 in the last 30 years is to bootstrap into gcc. C72 didn't have void . or function prototypes. In K&R C you defined functions as:
func(x, y)
int x;
double y;
{
}
The ISO standard for C didn't appear until 1989, and that's been superseded by C99 and C11.
You should at least be using C89. Preferably C11. Get with the current century, man!
|
|
|
|
|
Quote: "bool" is not "standard" C/C++ type
wrong
Quote: when "condition" such as in "if(condition)" evaluates to true , it is binary zero
wrong
Quote:
thus if(condition == 0) would make better sense then if(condition)
wrong
Quote: most "well written functions return x" , x being mostly zero when function is successful
when function fails – the return value is (generally) -1 or positive value identifying the error
then same as above - if(function (z) == 0) should prevail.
(Some) 'functions', yes, 'well written functions', no. To return an integer value of 0 as a sign of successfully finishing a function used to be the standard 30 years ago, because, most of the time, there was only one case of 'success' you were interested in, but potentially many cases os 'not success'. Since the type bool didn't exist back then, integers were used instead, and that opened the opportunity to use return values as error codes, where an error code of 0 was generally considered 'success'.
Then, when the first attempts were made to introduce boolean types into the language (typically impementation-dependent), some people tried to adapt to this change by declaring the integer value of 1 as indicating success in functions that only ever returned 'success' or 'failure', rather than an error code.
Unfortunately, that led to some confusion from the camp of programmers who liked the ability of returning various different error codes. This led to some unholy alliance of the different paradigms, where a value of 1, or, in fact, every positive value, was considered success, whereas negative values were considered error codes.
These different methods of returning integer values with the dual meaning of 'success/'failure', as well as an error code has survived til today. But nowadays, the correct way to report an error is throwing an exception, not returning a value! This lets you use the return value in the original sense of a function: returning the result of the operation.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|