I'm trying to create dialogs that 'lock' the parent window, but without touching the gtk_window_set_transient_for function.
I notice that Glade allows me to set Transient For and Attach To values, but if I connect those with my parent window (defined in the same glade file) and run the program, it is not transient.
Do I need to do anything else? Does this way even work?
So it does work. I didn't fully realize however that the a locking dialog also needs to be set to be modal.
So to solve my issue I had to also tick the Modal property.
Furthermore, it's also important that both the dialog and the window are loaded from the same builder instance.
Related
I want to add custom actions to every window's title bar context menu. The goal is to add an option like in the task view where you can move a window to a different virtual desktop. I was able to do this with hotkeys using GlobalHotKey and WindowsDesktop packages in C#. But I want to do it in the UI as well similar to some Linux desktop environments.
I know you cannot normally do this with the registry like you can with other context menus. When creating your own application I know you can use GetSystemMenu, AppendMenu, etc. and override WndProc to handle it. But this obviously will not work for what I am intending.
The application Moo0 Window Menu Plus achieves the desired effect but I have no idea how they do it.
I have a feeling the solution is probably somewhat hacky but I would still like to know how it could be done. I am open to using any language to achieve this.
You need to inject into the process, that is the only way to add a menu item.
A shell hook will notify you with HSHELL_WINDOWCREATED when a appropriate window has been created. You can then inject into the process (with another hook type or CreateRemoteThread). Once you have your .DLL in the process you can subclass the window and change the system menu.
You need to create both a 32-bit and 64-bit injection .DLL and I would recommend that you write it in native code, not C#.
I am trying closed property sheet dialog directly in my code which created using OleCreatePropertyFrame API. for closing the dialog box I am using PropSheet_PressButton API but i don't know the how to get handle for property sheet dialog.please if anyone know about this suggest me.
It does not really make sense to close a modal dialog if you don't control any of the code inside it.
You control the owner handle so that might be your best option; look for a enabled and visible window owned by your window. Perhaps GetWindow(yourWindow, GW_ENABLEDPOPUP) or GetLastActivePopup. This is slightly hacky of course but what you are doing is not normal.
I have added a .Net windows form inside a saleslogix windows plugin, every thing is working fine but on pressing the "Tab" key inside this control, instead of going on the next textbox the control goes to next plugin.
I have searched it a lot and can not find a work around for this, when I added a browser control in another saleslogix windows plugin, the page inside this textbox has multiple text boxes in it. To my surprise on pressing the tab key it worked perfectly and control goes to the next text box.
Any help is much appreciated.
That's an entirely normal mishap when you use Winforms (and many other UI class libraries) in a host application. Navigation keys, like Tab and the cursor keys as well as shortcut keystroke keys, need to be recognized regardless which control has the focus. One way to do so would be to implement the KeyDown event handler on every single control. That's excessively painful of course.
So it doesn't work that way, the keystroke is recognized when it is received by the message loop, before it is dispatched to the control with the focus. Overriding the ProcessCmdKey() method is the general way to do this. The base method takes care of navigation and recognizing menu and button mnemonics.
Problem is, it isn't the .NET message loop that is receiving and dispatching messages. It is the host application that has the loop. And it doesn't know beans about ProcessCmdKey(). So it doesn't get called and navigation doesn't work.
It tends to work in a WebBrowser because it is an ActiveX control. Which is designed to interact with its host. In particular it negotiates to decide which one gets to process the key. The IOleInPlaceActiveObject::TranslateAccelerator() method does this. Not the kind of plumbing available in .NET and host apps are rarely written to provide an alternative.
You could consider the "excessively painful" solution but pretty unlikely you like the sound of it. There's only one other decent way to fix this, you must call ShowDialog() to display your form. Now it is the .NET loop that dispatches and the Tab and cursor keys work fine. That tends to be unwelcome advice, dialogs can be pretty awkward. If you are lucky and know what you're doing and the host can deal with it (usually not) then using a thread can take the sting out of the modality. Asking the vendor for advice, particularly the threading aspect, would be wise.
I'm doing an automation script for installation wizards using AutoIt. I'm trying to handle window changes in some way.
Can some one explain how these GUI's work?
When I click on the Next button it looks just like the components in the GUI is beeing changed. Is this tha case? Or is a new window created and the old destroyed?
I've noticed that the process ID is the same for all windows.
I'm sure there is some way to know which "state" the GUI is in, or which step?
By the way. All the windows has the same title.
Thanks
/Anders
This will be dependant on the program you are automating.
The easiest approach would be to look at what changes in the GUI between stages, likely candidates are if there is a label that is giving instructions for that step, or a button that has text changing (e.g. if the button says "Finish" then you know your at the end).
Most installer programs have child windows for grouping the controls of each stage. These are typically implemented as dialog resources (as can be seen when using something like reshacker on them). So although the window remains the same, the panels are being created/destroyed as appropriate. This is a very neat method of doing it, for the obvious reason that you don't need to have to code to create/destroy a lot of controls. Resource created dialogs don't have nice class names like windows sometimes do though, so this may not be a reliable way to check the state.
I know it's possible to take a dialog that you built yourself and parent it on another form. But is it possible to parent a standard Windows system dialog on a form that you designed?
Specifically, I'm trying to set up a form with multiple tabs that provide different ways to obtain a reference to data used by the program. One of those tabs should represent the file system, and the ideal way to do this would be with the standard Open dialog that can be instantiated with the COM identifier CLSID_FileOpenDialog.
Is there any way to take a system dialog and cause it to appear parented on another window, without the border, title bar, etc?
There are ways to use a hook, either via SetWindowsHookEx() or SetWinEventHook(), to grab a system dialog's HWND, then you can do whatever you want with it, such as call SetParent(). But just because you CAN does not mean you SHOULD. System dialogs are designed to run as their own windows, not embedded in someone else's window. A better solution might be to use the same Shell display components that are used by Windows Explorer (and system dialogs) via IShellFolder::CreateViewObject() or SHCreateShellFolderView(), or find a third-party solution that does the hard work of interacting with the Shell for you.