I have a Window with some widgets. This window is already visible. Then I create a new List and push it into this window. There I have a problem: the names of columns are displayed, but the rows itself not. Sometimes it works correctly, everything is displayed (the rows), sometimes not, but have to. BUT! When i hide the window and open it agan the rows appears.
May be you have any ideas about that or has someone encountered this?
Gtk (the underling library) refreshes its windows under two circumstances: when a window's outline is changed on screen and when the user tells it to refresh the widow. Gtk.jl, however, does not itself tell the Gtk package to refresh when you change the contents of the listing.
See also: GTK+ - Refresh a scrolledwindow
So you do need to refresh the listing window yourself, and hiding and showing the window with each change in the listing is quick enough with Gtk for that to be fine as a solution unless you are doing hundreds of such changes, in which case you might want to only refresh the window after the changes complete.
Related
I have inherited a Qt-based app that handles the master/detail relationship by presenting the detail screens as separate windows. The main window includes a list, and when you tap on a row a separate detail window is opened up.
In the code base, the detail windows are handled by a QML file and a matching .cpp file (the main window also has its own .cpp file). The problem I am facing is that a new client wants me to modify this application for them, except that they want everything to occur within a single window. They want the list to be shown on the left side, and then when a user taps a row, the detail screen is to be shown on the right side of the window in its own panel (but not in a separate window).
For various reasons I can't easily refactor this application. A quicker solution for me would be to continue to present the detail screen in its own window, but to make it a borderless window and position this borderless window over top of the main window (on the right) so that it appears to be a panel within the main window.
Is something like this possible with Qt? I have written Windows apps in the past that hooked into the Windows API to do something like, but I don't know whether this is even possible in a native Mac OS app, so I don't know whether Qt can handle it in some way automaticaly.
One thing you could try is to create a widget based "main" window and then use QWidget::createWindowContainer() to wrap the QtQuick windows for positioning them with QtWidget means, e.g. layouts.
Windows 10 SciTE 3.6.6
I have a window with a toolbar that contains a drop down that I am trying to get a value from but I am unable to find the window handle
The menu and item looks like this
I need to wait for a process to finish (but nothing is busy so waiting for a window does not seem to help). I know for sure that the process is finished if this drop down contains a 1, it will be blank while the process is running. I could also check if a sub menu item under Documents is enabled, but I have not been able to find a handle to the menu either.
When I drag the selector from AU3Info over the item outlines the main window and all values in the Control tab are blank
I need to find what key the user pressed on a keyboard using xamarin.forms, ideally inside an AbsoluteLayout. I've come up with a few ways myself, but can't get any of them working.
As there isn't an event for this on the AbsoluteLayout control, i tried a little cheat, which was putting an entry field (textbox) on the screen, but hiding it above, so it can't be seen and using the result from that, but it loses focus when someone presses the screen or a button on the screen. so i tried adding an event to each button which refocuses the textbox once i've handled the press and this seemed ok at first, however, if they press anywhere else on the screen, it also loses focus.
I also tried adding a TapGestureRecognizer to the screen, and focusing the button when they press anywhere on the screen, however, there were 2 issues with this, the first being that it appears to only fire when something inside it is touched, and secondly, when i call the focus method for the second time (if they click the screen twice) it un-focuses the entry field, even if i check "isfocused" first (think this is a bug).
I'm only concerned about windows 8 and android apps so far. iOS may come later, but for now im just trying to get it working for these OS's. so maybe i could code it in the windows and android projects (inside my shared project solution), however, i have absolutely no idea where to even begin doing that. I mean, if this is the best way, how can i pass my AbsoluteLayout to the windows project and get it to know what it is, and convert it into a control which i can then add the event to.
Any help or advice, or ideas would be much appreciated. I cant find anything in NuGet which will help me with this. Any ideas?
Many thanks
James
Situation: As the central widget of my application I have a QMdiArea in tabbed mode (wrapped in a custom class that inherited from QMdiArea). When I now add the first QMdiSubWindow via addSubWindow() everything is still fine, meaning the window and its contents are maximized to take up all the space of the QMdiArea. However, as soon as I add a second sub window, the following problem arises:
Problem: The content of the second window is not displayed, but instead the content from the first continues to (despite the fact that the second tab visually has the focus), but is reduced in size. It only takes up a few pixels. But if I now switch back to the first sub window/tab (either by clicking into the size-reduced widget which then automatically goes back to max size or by selecting the first tab header) and then selecting the 2nd again, all is fine = the widget/editor of the 2nd tab is now displayed and is maximized.
But only until I close the second tab, in which case the content from the first is displayed (as expected), but again only in the small size!
Screenshot:
Another related test case: 1st tab is created and is displayed full size as expected. If I now simply resize the overall QMainWindow, suddenly a faint border appears around the widget in my tab. So it appears to be in a mixed state between maximized and normal mode with borders. Does that create any new leads?
Screenshot:
I am so far not using any explicitly defined layouts, but given that the first tab works fine and after manual back-and-forth switching all others as well, I assume that it should work without.
Do I need to set explicit layout objects? Why does it work for the first tab, but not the second?
Some code as a base: This is the logic executed in my custom QMdiArea class that takes care of adding the new children:
// Note: pEditor inherits from / is a QMdiSubWindow itself
if(!pEditor->isInitialized())
{
pEditor->initialize();
pEditor->setWidget(pEditor->getEditorWidget());
pEditor->setInitialized(true);
}
pEditor->beforeDisplay();
addSubWindow(pEditor);
pEditor->showMaximized();
// HACK START
pExisting = subWindowList().at(0);
if(pExisting)
setActiveSubWindow(pExisting);
// HACK END
Update: Added the hack proposed by N1ghtLight. Marked as such in the coding.
Update 2: Edited / correct problem description + new test-case with screenshot.
After many hours of comparing the example project from N1ightLight to my own implementation, I finally came across the central differences. There were in fact two issues at play:
For some reason I had the following line in the creation of my MDI sub windows, which apparently screwed up the size handling. Getting rid of this line removed any need for the previously proposed hack. Combined with the layouting proposed by N1ghtLight, all size changes are now handled gracefully.
setWindowState(Qt::WindowMaximized); // do not use that state!
The second part regarding the tab closing (closing one tab did not bring up the next tab in the expected manner and size), is actually explained in the Qt documentation:
When you create your own subwindow, you must set the Qt::WA_DeleteOnClose widget attribute if you want the window to be deleted when closed in the MDI area. If not, the window will be hidden and the MDI area will not activate the next subwindow.
Since I was creating my own sub windows I had to set that flag, but I never did because I wanted to prevent Qt from automatically deleting my content widget as well. My solution now is that I set the flag, but whenever a MDI child is about to be closed, I remove the link to the widget, so Qt cannot delete it.
void CustomMDIWindow::closeEvent(QCloseEvent* pEvent)
{
setWidget(0);
pEvent->accept();
}
I will mark my own answer as the correct one, but will award the bounty to N1ightLight since his support eventually led to me finding the final solution.
The ugly workaround really can be the calling of setActiveSubWindow() twice: First for some available sub window and then for the newly created one. This should emulate the situation when you click on the first tab and then return to the second one.
I need to keep a NativeWindow I am creating on top of the main window of the application.
Currently I am using alwaysInFront = true, which is not limited to the windows in the application. I can successfully synchronize the minimize/restore/move/resize actions, so the top window behaves appropriately in those cases. Even though using this option has the drawback that if I alt-tab to other application the window goes on top of the other application.
Because of the above I am trying to get it to work without using the alwaysInFront. I have tried using orderInFrontOf and orderToFront, which gets it in place but when I click an area in the main window the top one becomes hidden i.e. air makes it the top one.
I have tried capturing activate/deactivate events but it only happens on the first click, so on the second click the top window becomes hidden again. I also tried making the top window active when the main one becomes active, but that causes the main one to loose focus and I can't click on anything.
Ps. I am doing this to improve the behavior of a HTMLOverlay I am using - see Flex Air HTMLLoader blank pop up window when flash content is loaded
Listening for Event.DEACTIVATE and calling event.preventDefault() should work. Not sure if that is what you have tried, but I have an app where that does the trick.
I ended up turning on/off the alwaysInFront option based on whether the main window or the top window were active i.e. if none where active I turned it off. This was additionally to what I mentioned in the question.
That way when the user switches to another application, the window doesn't go on top of the other apps. I still would prefer a solution where I don't have to use the alwaysInFront option, or even better an alternate solution to the flex loading flash in external sites issue I linked to above.
Ps. I will try to check with the owner of the HTMLOverlay to submit a patch (its an improvement, although its tied to an app that doesn't open extra windows when opening the overlay).
Update: I have committed the changes to the HTMLOverlay.
I'm trying to do something very similar. In an AIR application, I have one large full screen window which is essentially the "desktop". I always want this window to stay behind all other windows in my app. There are, however, some items on the "desktop" window that need to be clickable.
There appears to be no clean way to force a window to maintain its position in the window ordering.
What I've settled on so far, which isn't perfect, is to make all other windows in my app use the alwaysOnTop property but bind this to a global var (ugh) that I maintain to track the overall application level active/inactive state. This way, when I switch to another app, my windows don't float above the all other app windows - they correctly move behind as expected.
Then, I have a regular (alwaysOnTop=false) window that is fully transparent as an "overlay" to the desktop window on which I can place various interactive controls. This window is OK to come forward since it's transparent and my other windows are alwaysOnTop.
Finally, and crucially, I install three event listeners on the "desktop" window as follows:
protected function onApplicationComplete(event:Event):void
{
this.addEventListener(MouseEvent.MOUSE_DOWN, onClickHandler, true,1000,true);
this.addEventListener(MouseEvent.CLICK, onClickHandler, true,1000,true);
this.nativeWindow.addEventListener(Event.ACTIVATE, onActivateWindow,false,-1);
}
protected function onActivateWindow(event:Event):void
{
trace("sent via activate to back");
orderInBackOf(bigTransparentWindow);
}
protected function onClickHandler(event:MouseEvent):void
{
trace("sent via click to back");
orderInBackOf(bigTransparentWindow);
}
I'm not entirely happy with all this since there is still some occasionally noticeable flicker of objects in the overlay window - it appears that the "Desktop" window gets ordered in front of it, an update of some sort happens, and then it gets forced behind again.
Any better solutions welcome!