So I have looked through existing answers tagged with dockpanel-suite and have not found what I am looking for (as I type this, it is also not appearing in the Similar Questions area). For starters, note that I am NOT asking about saving and restoring the entire Workspace.
So here is the scenario. I have a graphical window (we will call it "Timeline") that is added upon user request. When it is added, it is automatically docked to the bottom-most area of the main form. The user then takes the Timeline window and redocks it somewhere else (could be docked to an edge, or within another docking pane) and changes its docking behavior (floating, auto-hide, tab, etc.).
A demonstrable example is in Visual Studio. If you have the Solution Explorer on a tab within an docked pane on the right and close Solution Explorer, you can go to View -> Solution Explorer and bring it back up again, and it restores to the correct location.
Now the user closes the Timeline window entirely by hitting the [x] on its pane, and in the future, they request to add it to the application again. I want to bring it back in the last dock state and position it was in when it was last closed.
Now, I appear to be able to catch the closing of the pane with the ContentRemoved event, but in there e.Content.DockHandler.Pane, e.Content.DockHandler.PanelPane and e.Content.DockHandler.FloatPane are all null so I have no obvious way to get the previous dock geometry. e.Content.DockHandler.DockPanel is valid, but it is the parent/root docking panel, and calling SaveAsXml(...) does nothing for me because it would get the entire workspace.
Even if I were able to capture it here, information I need. However, I do not appear to be able to simply call LoadFromXml(...) on anything either.
If I try to do it before the DockContent object is added to the DockPanel, DockHandler.DockPanel member is null, so I appear to have no place to restore the XML into, even if I was able to get it.
There are no other events hanging off of DockPanel that seem to be able to help me here.
So - is there a way to do this, and what is the correct way to do it? I want to make sure I am not barking up the wrong tree with trying to capture the dock information as XML when closed and restore it later.
I have toyed with the idea of not actually closing the window but just undocking and hiding it, but have not explored that very far yet. Same with hooking the DockChanged event, but it does not seem to fire on the DockContent objects being docked/floated/etc. and I am not sure why.
Also the solution needs to be robust enough so that I can correctly handle scenarios such as if the last docking parent no longer exists. For example, if it was docked as a tab somewhere, but now that parent window (containing the tabs) has also been closed. I do not know if LoadFromXml, presuming it is the right way to do, is robust enough to handle this scenario, as I have not been able to test it yet.
If I understand the question, what I do is to trap the Closing or FormClosing event, .Hide() the form and set e.Cancel = true. If you are using DockContent, then there is a HideOnClose() that does the work for you. Then when you want to "re-open" the window, you simply use an empty .Show(), and it will Show right where it was when you "closed" it.
As far as saving if the last docking parent no longer exists, I agree with Lex Li, that will take a hack.
Related
It was easy when the Windows' explorer was using a SysListView32 control for displaying its files list as opposed to the DirectUIHWND control in the subsequent versions of Windows after XP.
A simple task such as obtaining the 'hot item' which is that item (a filename) the mouse hovers above for some hundreds of milliseconds, where before I could use the macros
ListView_GetHotItem with ListView_GetItemText and be able to obtain the filename under the mouse cursor.
This simple task becomes almost impossible to do with the DirectUIHWND window unless I revert this control back to a
SysListView32 which I have seen being proposed as the only solution on the many sites I have searched, and even if used the change does not occur immediately but only after I navigate out of the folder first.
It has taken me almost 2 years trying to find a solution to this and until now I feel stumped.
Anyone any idea please ?
Basically I have subclassed the parent of the tooltip and intercepted the tooltip notifications and all I need is the filename and the full path of the item the mouse hoovers above it, the hot item.
https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/march/windows-2000-ui-innovations-enhance-your-user-s-experience-with-new-infotip-and-icon-overlay-shell-extensions
IQueryInfo is required to provide the runtime text to the shell. IPersistFile is used by Explorer to let the extension know about the specific file currently under the mouse pointer.
In child window of my application, I have placed one single line edit control named as sle_name. Its tab order is 1.
Below that control I have placed DataWindow having formatted as free form style.
When I run the app, if my focus is in sle_name, and I click on sle_name then rbuttondown event is triggered. Then I move my focus to DataWindow(dw_account). Once I got focus on dw_account and then if I try to click on sle_name, my focus is not moving on sle_name and neither I can run rbuttondown event on sle_name.
What is the reason for this problem?
One more thing: when I start this window my focus in set in sle_name, from that control if I press tab key then my focuse moves to dw_account and if I press again shift+tab then my focus is moved back to sle_account.
But if I try to set focus from dw_account to sle_account using mouse pointer it is not moving focus.
What is the reason behind this behaviour?
I had the same behavior in a child window.
It was fixed when disabled the 'ControlMenu' and 'TitleBar' properties in the window. (It's so strange).
Hope it helps
Juanma
This isn't natural behaviour, so the cause is likely something you've scripted. Depending on your architecture, the culprit code could be a number of places (e.g. framework objects). If this were my problem, I'd run with the PBDEBUG trace turned on (a System Option in the IDE, or /PBDEBUG on the command line after the deployed EXE name), and see what is firing when you try to move back to the SLE.
I'd also be using PBL Peeper to see the trace and the code side-by-side, so it's easier to see what code is being executed (the trace only shows you script name and line number).
Good luck,
Terry.
you must have to create the event ID pbm_lbuttonup, with the same parameter as rbuttondown event. Then in the code you write this.setfocus()
I have a rather unusual question, namely, how is called this window from icon tray?
I would like to make it in my application, and I could not find his name. I would ask for some information, or the name, the rest I should have to deal with.
The Windows UX Guidelines don't say anything about it. From my perspective it's just a normal dialog, albeit one that has rather immediate actions (as opposed to first clicking on an OK button of sorts) and resides in a fairly small size in a specific location. It is meant to be opened, interacted with quickly and then dismissed, never being the center of your attention. If your idea fits those criteria as well, then go ahead. It's easy to recreate with standard means.
I am trying to insert a custom widget into the Internet Explorer 8 url bar, next to the stop and reload buttons. This is just a personal productivity enhancer for myself.
The "window model" for this part of the IE frame is an "address bar root" window that owns the windows which comprise the IE8 url bar: an edit box, a combo control, and the stop and reload buttons.
From another process, I create a new WS_CHILD window (with a custom class name) that is parented by IE's address bar root window, thus making it a sibling of the edit box and stop/reload. I call SetWindowPos with an hwndInsertAfter of HWND_TOP to make sure it appears "above" (i.e. "in") the urlbar. This works nicely, and I see my window painted initially inside the IE urlbar.
However, when I activate the IE window, the urlbar edit control jumps back in front of my window. I know this is happening because I still see my window painted behind the urlbar, and because when I print ->GetTopWindow() to the debug console on a timer, it becomes the HWND of the urlbar edit control.
If I update my message loop to call SetWindowPos with HWND_TOP on WM_PAINT, things are better -- now when I activate the IE window and move it around, my control properly stays planted above the edit control in the urlbar. However, as soon as I switch between IE tabs, which updates the text of IE's urlbar Edit control, my control shift backs behind the Edit control. (Note: This also happens when I maximize or restore the window.)
So my questions are:
1) Is it likely that IE is intentionally putting its urlbar edit control back on top of the z-order every time you click on a tab in IE, or is there a gap in my understanding of how Windows painting and z-ordering works? My understanding is that once you specify z-ordering of child windows (which are not manipulable by the end-user), that ordering should remain until programmatically changed. So even though IE is repainting its Edit control upon tab selection whereas I am not repainting or otherwise acting upon my window, my window should stil remain firmly on top.
2) Given that the z-order of my window is apparently changing, shouldn't it receive a WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED? If it did, I could at least respond to that event and keep myself on top of the Edit control. But even though I can see my window painting behind the urlbar Edit control when I click on a tab, and even though my debug window output confirms that the address bar root's GetTopWindow() becomes the HWND of the Edit control when I click on a tab, and even though I see WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED being sent to the Edit control with an hwndInsertAfter of HWND_TOP when I click on a tab, my own window receives no messages whatsoever that would allow me to keep the z-order constant. This seems wrong to me, and addressing it would force me to run in IE's process and hook all messages sent to its Edit control just to have an event to respond to :(
Thank you for your help!
It's quite likely that IE is juggling the Z-order of the controls when you change tabs. In IE9, the URL bar and the tabs have a common parent. When you select a new tab, it activates the URL bar (and activation usually brings the window to the top of its local Z order).
No. You get WM_WINDOWPOSCHANGED when a SetWindowPos function acts on your window. If some of the siblings have their z-orders changed, you don't get a message. Nobody called SetWindowPos on your window. You can see this by writing a test program that juggles the z-order of some child windows.
This makes sense because there might be an arbitrary number of sibling windows, and it could be an unbounded amount of overhead to notify all of them. It also would be nearly impossible to come up with a consistent set of rules for delivering these messages to all the siblings given that some of the siblings could react by further shuffling the z-order. Do the siblings that haven't yet received the first notification now have two pending notifications? Do they get posted or dispatched immediately? What if the queue grows and grows until it overflows?
This is different from WM_KILLFOCUS/WM_SETFOCUS notifications in that it affects, at most, two windows. That puts a reasonable bound on the number of notifications. Even if there's a runaway infinite loop because the losing control tries to steal the focus back, the queue won't overflow because there's only one SetFocus call for each WM_KILLFOCUS delivered.
Also, it's reasonable that windows might need to react to a loss of focus. It's much less likely that window C needs to know that B is now on top of A instead of the other way around, so why design the system to send a jillion unnecessary messages?
Hacking the UI of apps you don't control and that don't have well-defined APIs for doing the types of things you want to do is anywhere from hard to impossible, and it's always fragile. Groups that put out toolbars and browser customizations employee more people than you might expect, and they spend much of their day probing with Spy++ and experimenting. It is by nature hacking.
I'm wondering how I can give the focus back to the window that it before my window got it. I've looked around and so far only seen functions to get, not release, focus.
I wonder if you just need the focus released, or do you need to focus on another entity instead, after releasing the focus from said entity?
If you need to know previous widget in your form tab order, take a look at QWidget::nextInFocusChain and QWidget::previousInFocusChain. You should be able to get next\previous widget in your widget's focus chain. Once you know it, you can pass focus to it.
If you're looking to get next\previous window in Z-order take a look at winapi GetNextWindow function (GW_HWNDPREV in wCmd parameter will return a handle to the window above the given window). Once you know the previous window you can bring it back to from using BringWindowToTop
hope this helps, regards