Good morning,
In our company, we use again WIN32 with dialog box who has been created in DLG file extension.
Let me tell you.
In DLG file, we define set of dialog box and windows who is gonna be used in our application.
And in the code C or C++, to call one or another DialogBox, we use the standard function DialogBox or again DialogBoxParam. For every dialog box, we use a file as controller who contains a WinMain with events loop in order to manage button clicks, hidding components, and so on.
There is a dialog box wherein I would like to use tab control. Is it possible to put every tab control with its components in my '*.DLG' file and to call it in my code C++ in order to be used not as window but tab control ?. If yes, how ? Otherwise, I stay opened to each other possibilities.
Thank you
Related
I'm developing a GUI in Linux (Ubuntu 16.04 - WM: Gnome) using GTK+3 and the graphic library cairo.
After clicked on a push button (Plot), using the instruction of cairo I draw a red square on a new top window where I put a GtkDrawingArea.
In this window I also put a push button (Cancel) that clicked, hide the window. In this way, if I re-push "Plot", the red square reappear.
The issue is the "x" icon present in the top bar of the window.
If (no me) a user push this x, the window disapper and if he re-push the "Plot" an error is reported.
The question is: it is possible avoid this possible cause of error?
(remove this "x" from the top bar of the window or in some way disable its functionality).
I tryed to find alone a solution and the possibility found are:
1 - Remove from the window the property of "decorated".
The top bar disapper (so also the x) but is not possible move the window on the screen
2 - Using the function gtk_window_set_deletable(window, FALSE) (used before to show the window), but the x is always there and pushing it the window is destroyed.
If you think that can be useful, I can report the code.
I'm waiting your suggestion.
Edit:
Now we know what you want to achieve: display a separate window but avoid destroying it so you can display it again. You already have in the "Cancel" button of your secondary window the logic to hide it.
The cleanest solution is to just do the same: when the user tries to close the secondary window, hide it instead. This way the user is not frustrated of seeing something that apparently doesn't work as expected. Hidden or closed, it's different for you but it's the same for the user.
So you just need to connect to the delete-event of that secondary window, and hide it. There's even no need to create a specific callback for that, GTK+ provides it for you: you just need to connect the delete-event to gtk_widget_hide_on_delete. To display the window again, just call gtk_widget_show_all on it.
Original answer:
I realize the plot
"realize" is a term that has a defined meaning in GTK+. Don't use it out of context, and try to use an alternate term if you're not talking about widget realization.
What I would like is to remove this "x" from the top bar of the window
or in some way disable its functionality.
Do you understand this is ultra annoying for a user and defeats a unified user experience? Would you like to use applications that do random different things?
Anyway, one way of disabling the closing button is to connect to the delete-event and return TRUE there to stop the propagation of the event. The button will still be there but do nothing, so you will have to kill the app to exit it.
To make the button disappear, gtk_window_set_deletable will ask the Window Manager to do that, but we'd need some code to know what's wrong with your attempt.
My goal is to have a single icon for all the windows of my application.
After some reading, my understanding is that creating a tray icon is achieved through Shell_NotifyIcon(). This function gets a NOTIFYICONDATA structure which contains a hWnd field. This HWND is used by the system to notify the corresponding window of tray icon events. These events are handled by a WindowProc callback that is set on the window with SetWindowLongPtr().
Hence my questions:
How can a single icon notify all the windows of my app of say a left mouse click ?
Can I Shell_NotifyIcon() multiple times with different NOTIFYICONDATA structures, each one with a different hWnd, but with the same icon ?
What if the original window that got registered for creating the tray icon is destroyed ?
Would creating a hidden proxy window be an appropriate solution ?
Some background: my application calls the WinAPI with C (using js-ctypes), and should ideally work on all Windows versions from XP on.
You practically answered your own question in the question itself. The best thing to do is create a hidden window that survives as long as you need the tray icon to exist.
You would call Shell_NotifyIcon() only once with the hWnd referring to this hidden window, and have this window post the messages to the individual windows that need to receive them.
This also gives you the flexibility of being able to decide to skip sending messages to a particular window, or being able to send a different message to each window, depending on the requirements of your particular application.
I am working on a WinForm Application.
The Form has many fields/components but is poorly built.
for example a field is used as user name on one case and used as folder path on the other case. Code is quite poorly maintaned.
Is is possible that when i run the application and GUI appears, i can use a tool like 'spy++' which can show me 'names' of the components (not ids). For instance the name of a button or name of a label.
Or if i can use SPY++ for 'names' please tell me?
I would solve the problem by adding a ToolTip control to your form and iterating over each control and adding a Tool Tip message to each control that is the name of the control.
First, add a ToolTip object to your form (from the Tools section of the designer.) You can rename it, but for the sake of my demo, I left it as the default name toolTip1.
Next, add a method similar to the one I'm posting below to the code page of your form. (I'm assuming this is for C# but the code is simple and can easily be modified for VB or C++).
public void AddNameToToolTip(Control c)
{
toolTip1.SetToolTip(c, c.Name);
foreach (Control child in c.Controls) AddNameToToolTip(child);
}
Finally, from within the Form constructor, add the following line of code after the call to InitializeComponent().
AddNameToToolTip(this);
This will add a ToolTip message to each control in your form. All you should have to do is hover your mouse over each control and the ToolTip will pop up a message after a second or two displaying the name of the underlying control.
Alternatively, you can recursively adding a MouseHover event to each control and when the event is fired, write the name of the control to the debugger. This would also work if you are already using a ToolTip control within your form.
I'm looking to add a 'close' button to my main window's menu. An example can be found in the picture here: http://ifyoucodeittheywill.com/img/crimson-editor.png
(So, there's the normal close button in the window caption area, but, there's also a close button in the window's menu bar -- on the far right).
I'm using basic win32 API's, though an example using MFC would also be fine.
Does anyone know how to do this?
Thanks,
Andrew
These buttons usually come with MDI windows. However I'm pretty sure the depicted application uses either its own, or more probably some advanced third party toolkit. Because, to be honest, what the Windows API and MFC (which is just a classed wrapper around the windows API) give you for GUI programming is unbareably limited.
If you want to design neat UIs steer clear from MFC and better have a look at something like Qt, wxWidgets or the like.
A really simple way of doing this is to use a regular menu item, using AppendMenu, but use the following flags:
MF_BITMAP with a close button bitmap, or MF_OWNERDRAW or to draw it yourself
MF_HELP (aka WM_RIGHTJUSTIFY), a not-very-well documented flag, which will justify the item to the right.
Here's one reference to MF_HELP that I found on msdn - it's actually about using the Win32 API to right-justify a menu item, but using Visual Basic.
MF_HELP (defined in winuser.h) is something of a holdover from Win16 days, back then, the convention was to right-justify the Help menu item, so it would stand apart. It was 'renamed' - an additional #define added with the same value - to WM_RIGHTJUSTIFY around Win95.
Note that bitmap menu items aren't accessible (eg. to users that are relying on a screenreader to read out where they are on the screen); if taking this approach, then at least add a regular 'Close' menu item elsewhere in the menus (eg. under File), so that a user doesn't have to rely on this item, and can also close it through usual means. Also be sure to implement the Ctrl-F4 shortcut, which is what most applications that support multiple documents or tabs use to close the current item.
By all means do not try to create this behaviour yourself. This is functionality that you get "for free" if you are using the MDI architecture of MFC. The close button "next to the menu" as you call it closes the active MDI child window. If you are not using the MDI architecture then there is no point in trying to add a close button there. Can you explain if you are using the MDI architecture?
Is there any way that I can show a window only when a pen/tablet is in use, just like the windows tablet PC input panel is only shown when a pen/tablet is used (and not just connected)?
You can handle or set a trigger for the UIElement.StylusInRange event to make your control visible. (Conversely there is a StylusOutOfRange event which you might need for hiding)