|
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)
|
|
|
|
|
OK,
essentially about using bool as a variable to evaluate only for two states
C still has no standard ( AKA what used to be defined in " ANSI C standard " ) "type" bool
Some coders just use #define - which is fine but hides the essential programming of checking something for these two values - sort of unnecessary crutch.
C++ has "type" bool but evaluates to something called "true " or "false" which in reality is "something / application/ os " or whatever dependent and hides the binary value of these symbols. Hence no "standard" in sense of "ANSI C standard " again.
|
|
|
|
|
You are mixing C and C++, which only adds to your confusion. C++ and ANSI C are two distinct languages.
Vaclav_ wrote: C++ has "type" bool but evaluates to something called "true " or "false" which in reality is "something / application/ os " or whatever dependent and hides the binary value ...
No. The bool type in C++ is exactly that, a boolean type, and is part of the language, nothing to do with the operating system. A statement like
bool someVariable = true;
while (somevariable)
{
}
will continue until it encounters
someVariable = false;
But if you try
someVariable = 1;
the compiler may accept it byut you should not rely on it, as future compilers may well not accept it.
And conversely if you try the first two in C the compiler will not know what you are talking about. Decide which language you want to use and stick to it, it will save you a lot of confusion.
|
|
|
|
|
Richard,
why are you getting into your typical " blame the poster " mode?
I am not confused, just asked / posted a question and do not appreciate such comments.
"get off my lawn..."
|
|
|
|
|
Who is blaming? I merely mentioned out that you are confusing things by mixing two different languages. But as usual you get on your high horse as soon as anyone points out your mistakes.
|
|
|
|
|
Vaclav_ wrote: C still has no standard ( AKA what used to be defined in " ANSI C standard " ) "type" bool
Wrong. As of C99 (1999! 30+ Years ago!), the standard defined _Bool, and include <stdbool.h> which includes the macros
#define bool _Bool
#define true 1
#define false 0
In fact, in the comments to stdbool.h on my system I see
Vaclav_ wrote: C++ has "type" bool but evaluates to something called "true " or "false" which in reality is "something / application/ os " or whatever dependent and hides the binary value of these symbols. Hence no "standard" in sense of "ANSI C standard " again
Wrong again. The standard defines "true" and "false" as 0 and 1. Unless you use std::boolalpha, you normally get 0 or 1 when printing to an iostream (std::cout, etc).
Technically I think that the implementation is free to use whatever values "behind the scenes" to implement a bool, but its representation is as if it had a value of 0 and 1. The same is true for NULL. A given implementation may use any value it wishes to indicate a NULL pointer, but it has to act like a zero in certain contexts. I believe this was the case in the days when we had NEAR and FAR pointers. All the bits of a FAR NULL pointer might not be zero, as its segment selector might be set, but it would compare equal to zero, and equal to any other FAR NULL which had a different segment selector.
modified 21-Feb-20 12:03pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
