UI Glitches when using pyqt5+qml - pyqt

I have a windows application written in qml+pyqt5 (and run on a windows 10 tablet).
Sometimes after a tap or on page switch, the application's background turning white, while the buttons are still visible and can be clicked - once I click them or on the screen - the white background disappear.
Sometimes after a tap or on page switch, there are strange triangles appearing from random places, and disappears on tap or click.
There is no indication of this bugs in the app's logs, and they fixes themselves on tap or click.
I've noticed that it happens more frequently when there is animation in the page - do you think there is a connection between the things?
Do you familiar with the phenomena, and know by any chance what is the root cause of them and how to deal with it?

Related

Windows touch keyboard appearing in controls without text input

In MFC, how do I stop the touch keyboard from appearing when selecting controls without text inputs? Specifically, CComboBox-derived and original CListBox controls. The issue occurs in a large C++ application for touchscreen tablets running Windows 10. Bizarrely, selecting any CEdit control in the application solves the issue until the application restarts.
I've been looking at InputScope, AutomationPeer, and even killing the keyboard process TabTip.exe after it appears, but none of these prevent the keyboard from showing in the first place.
A previous solution involved changing the "Automatically show touch keyboard" registry setting SOFTWARE\Microsoft\TabletTip\1.7\EnableDesktopModeAutoInvoke on focus change, but alerting the touch keyboard with SendNotifyMessage(HWND_BROADCAST, WM_SETTINGCHANGE) added unacceptable delay to the UI.

Change taskbar menu in Tauri

I'm using Tauri and would like to change the menu items shown when clicking my application in the taskbar using the right mouse button (Windows/Linux) or double click (MacOS).
For example Firefox shows "Open a New Window" and music players often show "Play/Pause" or "Next track" buttons. How to do that with Tauri?
I'm aware of SystemTrayMenu in Tauri, but that only seems to affect the system tray, not the task bar.
(What I mean by "taskbar": the line of application icons that you click to open them, and that usually indicate which ones are running. I think MacOS calls it Dock, in Windows it's at the bottom between start button and clock, and Linux isn't very homogeneous but in Ubuntu it's vertically on the left by default. I do not mean the system tray of usually smaller icons that are almost always next to the clock, that are usually more like background services. I.e. I mean where your browser usually shown up, not where your VPN usually shows up.)
Tauri does not support this at the moment (2022-06-27). You may file a feature request.

Tool bars are getting rearranged

I am using VC++ MFC and have the following toolbars in my software.
While working with different screens and software is minimized, if we disconnect the other screen, the toolbars get messed up after restoring the application.
Also that issue occurs, sometimes, when using single screen and change screen resolution or laptop lid is closed and re-open it, most of the cases when application is minimized at time we change anything.
We are not executing any code as such to draw the toolbars every time. While software is starting up, we read the toolbar positions from registry and create toolbars, and while closing application, we read the toolbar current position and save it back to registry.
Please suggest what should I do to fix this..
Thanks...
From the details what i can say is, while you were working on screen of one size the application considering the toolbar co-ordinates in relation to that screen. But when screen changes the old co-ordinates are no more valid as new screen may have different size and that's what causing the issue.

Section at bottom of screen that doesn't respond to onpress event, what's causing this?

I'm working on an existing React-Native app, and in the iOS version, there's a problem where a portion of the bottom of the screen does not respond. At first it was thought to be on a specific screen, but upon further investigation, it was found to be affecting other screens as well. The control used on the first screen where the problem was noticed is TouchableOpacity, but a rectangular section in the middle at the bottom of the screen does not respond, but in either corner at the bottom of the screen it does respond. Another screen has a ListView, and if you attempt to scroll from that same bottom middle area, it won't, but everywhere else, it will. This is evident in both the simulator and on the physical device. It acts like there's something in the road floating over the top of everything.
I've tried using the Accessibility Inspector to identify the cause, but this hasn't revealed anything.
The highlighted area in the screenshot above is where I'm referring to.
To complicate things further, this problem doesn't exist in the Android version.
Has anyone experienced this before, and if so, what was the cause and how do I fix it?
Edit: I've now determined the cause is an Animated View that's hanging about, it seems not all the child elements within it are having their opacity set to 0. I've attempted to address this using pointerEvents, but this just moves the problem to a different child element.
Anyone have any suggestions?
The issue turned out to be that the parent was having it's height changed during the show and hide events to avoid this same issue in Android, so we need to only change it if the platform is Android.
this.setState({height: (Platform.OS === 'ios') ? 50: 0});

Why does the task bar appear when I display a self-drawn modeless dialog? .. sometimes?

I have an interesting (but frustraring) problem. I have an application which uses the full screen (this is meant to simulate a third-party fullscreen POS application).
My application displays a sequence of modeless dialog boxes on top of the full screen application. It shows one, hides it, then shows the next, hides it etc. After the 3rd show, the Windows taskbar appears about 1 second later. I can't figure out why.
I've stripped my code right back to see if its something I'm doing in my OnNcActivate handler (which I use to draw my skinned window) but I don't think it is as the problem appears to be timing related. I've tried running Spy++ as well as dumping messages in m WindowProc myself and I still can't see anything odd that would give me any clues.
There are some messages with ID 0x36e in my logs but I can't find out what they are supposed to be. I've checked various message ID lists and can't find them. They shouldn't be any message IDs of my own since WM_USER doesn't start until 0x400.
I know I could get around this problem by auto-hiding the taskbar but I can't ask our customers to configure their taskbars to auto-hide to get round my problem.
Any ideas why the taskbar would appear in relation to my modeless dialog boxes?
EDIT: I completely stripped out my self-drawn GUI code and I still have the same problem. I could be wrong but it would seem that when I call ShowWindow( SW_HIDE) first, Windows tries to activate "another Window" (as it says in MSDN). I think in this case its activating the taskbar rather than the POS application. If on the other hand I open my second window before calling ShowWindow( SW_HIDE ) on the second, then it seems to behave itself.
Cheers
Sparky
Following a long discussion I come to the conclusion that DestroyWindow was not the problem. I found in the end that displaying a dialog.. clicking on the POS, then clicking back on the dialog that sometimes the taskbar would appear. I have spent an entire week trying to find reasons for all of this but to no avail. I thought that assigning the POS window as the owner would solve the problem - it didn't. In the end the solution for my problem was to determine if the taskbar is obscured completely before showing my dialog. If it is, I hide the taskbar for the duration which my dialog is displayed (set its placement to SW_HIDE) and then set it to SW_SHOW when I close my dialog. The task bar doesn't pop up and annoy people anymore. Not a fantastic solution for other peoples' applications perhaps, but perfect for our customers.

Resources