This is the setting:
I have two views that are implemented within two different vcl forms. To one of those I applied a style to make it look like a touch optimized metro app.
Those forms can be switched according to an application's setting. (show touch optimized view on/off)
this works pretty good. I override Application.MainForm, the old form closes, the new form appears (and takes the focus).
I want this to be automated in Windows 10. As additional view mode I offer an option "Auto detect":
I am listening for the windows message WM_SETTINGCHANGE. This is sent by switching between desktop mode and tablet mode.
Then I check the registry for the value of HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\ImmersiveShell\TabletMode
If it's 1 I switch to the touch optimized view.
And this is the problem:
The old form is destroyed, the new form pops up and Application.MainForm references the new form.
Buf afterwards also the start screen of the tablet mode pops up and shows itself on the very top of all windows.
So my new touch optimized form disappears behind this screen and loses the focus. This behavior doesn't appear if I set the view fixed to the desktop view and switch windows 10 into tablet mode. in this case, my application keeps the focus and maximizes itself (that way there's no form created of course).
What I've tried so far:
The most obvious approach would be a call of
Application.MainForm.BringToFront.This doesn't work.
My second approach was to create a hidden "helperform" that takes FormStyle := fsStayOnTop (this way the focus should be taken) and calls SetForeground(Application.MainForm.Handle) from WinAPI.
any ideas?
Related
Im trying to retrieve typing information such as the on-screen coordinates of where a user presses a key on a keyboard on Android and iOS using flutter similar to how swiftkey does it to generate their heatmaps.
How would I go about doing this? Do I have to create my own custom keyboard
I've tried to implement the suggestion here: How to Calculate the Coordinates of touch in Flutter?
But once the keyboard drawer pops up, the on-screen coordinates do not register.
To do this you would have to show your own keyboard that you build in flutter. The reason for this is that the keyboard which pops up is actually a different android window (or at least activity, but pretty sure window and likely process as well), that is shown over top of the window that flutter is rendering into. By design, the keypresses can't be recorded as that would be a security issue (the active app is one thing, but imagine if another app could record keypresses or even location of taps - they could steal your passwords!).
There may be some android-specific way of doing it that I'm not aware of, but it probably won't work on all devices and all keyboards and is likely not a good route to follow.
In WindowsForms there is a property called TopMost that when True makes the window always in front of anything else in the desktop (like dialog messages). I'd to know if there is a opposite property in GTK+, in that when activated would make the window stay in the back of every thing on the desktop.
There's a line between the window manager's capabilities and what a UI toolkit can do. The toolkit takes care of the window's content, the window manager determines the placement and layering of windows. Such property is likely to be non-existent. It is potentially not feasible to implement the desired property across platforms (WMs) in a meaningful way.
Furthermore Gtk.WindowType only suggests only POPUP and TOPLEVEL.
Are you looking for a Gtk.StatusIcon for selectively showing and hiding your application window?
I'm experimenting with ways to have tooltips work across a variety of mobile devices. Unfortunately, the span of devices I need to support ranges from Nokias to iPhones.
Unfortunately, some of the browsers I'm dealing with don't support the use of the title attribute for tooltips on focus. As such, I need to come up with a different solution.
For starters, I'm playing with pure-css tooltips: http://psacake.com/web/jl.asp
This method uses the :hover pseudo class to position and set the z-index of a SPAN to create the tooltip.
On an iPhone, this produced an odd side effect. Tapping the link once exposes the tooltip require a second tap to actually activate the link.
However, applying a simple style to a different link's :hover pseudo-class (changing the background color) does not have the same effect. One tap triggers both the style and the link (you see the :hover style briefly before the next page loads).
I've solved this issue for mobile devices by switching to using the :focus pseudo-class which appears to not be triggered by the iPhone (and the Nokia touch device I am using). Of course, that's not ideal if this app were to be used on a desktop browser as well.
So...the question: Is there documented logic as to when the iPhone Safari browser decides to interrupt a click event on a link to expose the :hover pseudo-class vs. not interrupting and letting the link be triggered on the first tap?
I was trying to find you a link in Apple's documentation, but the most specific I could find about :hover was that it is emulated and can cause unexpected results. I did find one place that said it is only shown if the user taps and holds the object. That page (near the bottom, "Don't Use Unsupported iOS Technologies") also says that normal tooltips (using the title attribute) would be shown when that happens also.
If you will accept an assumption as to why the behavior is different for changing the style and displaying a tooltip, I would guess that it is similar to the way mousemove events are handled. This Handling Events page says that, if the contents of the page change during a mousemove event, the rest of the events in the chain (including mouseup) are not sent. I am assuming that this behavior also applies to :hover. If you are using display: none to hide the tooltip, you could try using visibility: hidden instead as it is interpretted as "the object is still here, but you can't see it."
I’m working on an interface in VB6 to interact with a sound editor to automate certain tasks mainly using the editor’s object handles and activating them through SendMessage/PostMessage. In general it works OK, except that the editor has some dialog boxes that open in modal mode and freeze everything on the interface, including the timers.
Is there a practical way to get these dialog boxes to open modeless or to interact with them from the interface after they pop up? I tried an MDI form, but it also freezes along with everything else. The only way to override the modal mode of these boxes is to launch an independent applet beforehand to address the dialog boxes with a timer, but the process is somewhat cumbersome.
All I need to do with the dialog boxes is click the OK button or hit the return key.
The Form.Show method excepts an optional style parameter that determines if the form is modal or modeless. You can pass it the intrinsic constant vbModeless.
Form1.Show vbModeless
It's a difficult question to answer without understanding the context of the dialog boxes. However, if you don't want the dialog to stall the execution of your program, I think the only way is to run your app from a different thread (start and Active X exe or something) and then make calls across to the other thread.
I'm having a sort out of my (Delphi) applications and I been visiting the floating form size and location persistence which seems to be increasingly important with larger screen real-estate and multi-monitors. Clearly it is often desireable to have a user's form reopen in the same place as they closed it, but maybe not always, for example a modal dialog might justify opening bang in front of the users vision, i.e on the primary monitor center screen. There seems to be little out there on the 'net about this and commercial applications seem inconsistent especially regarding multiple monitors. So, a few (probably contravertial!) rules to get us started...
Non-modal forms should always reopen at the size and location of closure.
Modal forms (i.e with OK/cancel, Yes/No buttons) should reopen at the
previous size (if sizeable), but inthe center of the monitor on which the application resides.
An information message box should open in the center of the monitor on which the application resides.
A warning or error dialog should open in the center of the primary monitor.
Thanks in advance,
Brian
"Non-modal forms should always reopen at the size and location of closure."
They must have a default position and size when they first open. Do you have
any rules about this?
I would add the qualifier: If the screen resolution/monitor count is
different from the last time this form was opened, then it reverts to default
position. So no inaccessible forms restored 400 pixels to the right and below
the screen area.
"A warning or error dialog should open in the centre of the primary monitor."
I don't understand why you move the messagebox from 'monitor where the app
resides' (henceforth MWTAR) to the primary monitor. You know the punter is
looking at the MWTAR; after all he has just done something 'bad'. Why are you
changing monitors now you have something important to say?
(After all, if it is an error dialog containing useful diagnostics, he won't
read it anyway. I don't see the need to hide it from him.)
A further thought. One problem with error modal dialogs is that, wherever they pop up, the user may hit 'Enter' accidentally while typing something else and dismiss it. I know I do this quite often.
One trick I have seen to overcome this is to disable the Ok button when the dialog is first displayed. There is a 3 second timer in the dialog which counts down, displaying the time remaining in a small label attached to the button. So the punter knows he will be able to dismiss the thing soon.
Obviously this must be used very, very sparingly, and only on the rarest and most important of dialogs. But it struck me as quite clever. Perhaps all that needs doing is to make Ok the default button after three seconds.
A dialog should never open in the center of the monitor. Consider one of the 30" monitors with 2560 x 1600 pixels resolution - using an application maximized on one of these monitors makes sense only in very specific cases. If an application form resides in one of the corners of that huge screen area then the user would need to move the mouse cursor from its current location to the center of the screen, and back after dismissing the dialog. Also, with a normal viewing distance it's probably impossible to have all of that screen in view at the same time, so center of the active window will be more "in front of the users vision" than the screen center. Any dialog that doesn't remember its position should open centered on its parent window. Exceptions should be made for dialogs that are bigger than their parent window (where it makes sense to leave a bit of the parent visible, which makes it more obvious for the user what's going on), and property pages that should appear near the objects they apply to.
I would also think about saving screen positions in percent of the screen area, not in pixels. This way using a laptop with and without a large external screen will always make optimum use of the screen area - using absolute coordinates will either have portions of the screen unused, or windows moved outside of the visible area.
Depending on the platform, when the application does not have focus when throwing up an alert it should avoid taking focus. Too easy for a user typing to dismiss the alert without any chance to read it.
E.g. on Windows make use of the ability to flash a task bar button.