I have a winform app that is hiding it's UI and waiting on a named pipe message before showing up
On receiving the event the thread invokes into the main UI thread and then does the following
Set the opacity to 100
ShowInTaskbar = true;
BringToFront();
ON Windows Vista the window does not show up on the taskbar though and the window is in the background . YOu cant say it
if you finally find it and click on it, it shows up on the taskbar
any ideas on how to fix this
i don't work in vista but it might be better just to flash the taskbar or do a ballon popup or something like that. What your suggesting maybe a bit annoying to a user. Say there typing away and there looking at the keyboard and your window has stolen the focus they look back and find what they just wrote hasn't gone into the app they thought it was going into.like this.
flashing the task bar
this might help also
If the form has an Owner set it might or might not show up in the taskbar.
Don't set the Owner property and it should show fine (it did for me).
Related
I'm developing a GUI in Linux (Ubuntu 16.04 - WM: Gnome) using GTK+3 and the graphic library cairo.
After clicked on a push button (Plot), using the instruction of cairo I draw a red square on a new top window where I put a GtkDrawingArea.
In this window I also put a push button (Cancel) that clicked, hide the window. In this way, if I re-push "Plot", the red square reappear.
The issue is the "x" icon present in the top bar of the window.
If (no me) a user push this x, the window disapper and if he re-push the "Plot" an error is reported.
The question is: it is possible avoid this possible cause of error?
(remove this "x" from the top bar of the window or in some way disable its functionality).
I tryed to find alone a solution and the possibility found are:
1 - Remove from the window the property of "decorated".
The top bar disapper (so also the x) but is not possible move the window on the screen
2 - Using the function gtk_window_set_deletable(window, FALSE) (used before to show the window), but the x is always there and pushing it the window is destroyed.
If you think that can be useful, I can report the code.
I'm waiting your suggestion.
Edit:
Now we know what you want to achieve: display a separate window but avoid destroying it so you can display it again. You already have in the "Cancel" button of your secondary window the logic to hide it.
The cleanest solution is to just do the same: when the user tries to close the secondary window, hide it instead. This way the user is not frustrated of seeing something that apparently doesn't work as expected. Hidden or closed, it's different for you but it's the same for the user.
So you just need to connect to the delete-event of that secondary window, and hide it. There's even no need to create a specific callback for that, GTK+ provides it for you: you just need to connect the delete-event to gtk_widget_hide_on_delete. To display the window again, just call gtk_widget_show_all on it.
Original answer:
I realize the plot
"realize" is a term that has a defined meaning in GTK+. Don't use it out of context, and try to use an alternate term if you're not talking about widget realization.
What I would like is to remove this "x" from the top bar of the window
or in some way disable its functionality.
Do you understand this is ultra annoying for a user and defeats a unified user experience? Would you like to use applications that do random different things?
Anyway, one way of disabling the closing button is to connect to the delete-event and return TRUE there to stop the propagation of the event. The button will still be there but do nothing, so you will have to kill the app to exit it.
To make the button disappear, gtk_window_set_deletable will ask the Window Manager to do that, but we'd need some code to know what's wrong with your attempt.
I´ve been working for some time on a good OSK solution for my WPF apps, that are running on a tablet. But it´s hard working with the OSK.exe and tabtip.exe, because of several bugs, strange behaviour and no standardized solution to this ordinary problem.
What I (probably) need is a custom textbox control, which inherits from System.Windows.Controls.TextBox, and overrides some methods.
The simple requirements for this textbox should be:
1. When a user clicks in a textfield, the tabtip.exe (or alike) keyboard should pop up at the bottom of the screen (default).
2. If the keyboard pops up on top of the textbox, the contentframe should scroll so that the textbox is visible.
3. When the textbox loses focus, the keyboard should close automatically, except if the user clicks on another textbox.
This seems like pretty standard behaviour right? Well I´ve looked a long time for solutions (there is no standard microsoft way which is kind of weird), and as said I´ve tried making my own but with no luck. For example, sometimes when I try to kill the process, it fails. When I click the close button in the upperright corner on the keyboard, like 5-6-7 times, it closes. The behaviour from PC to tablet is not consistent. The ScrollViewer.ScrollToVerticalOffset(x); sometimes doesent work on a tablet, and so on.
So does any of you know a good solution to this common problem?
I am working on the touch screen application which is running on Windows XP Standard. With current hardware to invoke a right click user has to click and hold for couple of seconds, but this might interfere with other actions like holding a repeat button in the scrollviewer, so I have decide to disable a right click.
I would ideally wan't to disable a right click on the application level, but if it is not possible, disable right click on windows level would also work for me.
The OnPreviewMouseRightButtonDown/Up approach did not work for me.
There is a property Stylus.IsPressAndHoldEnabled on UIElement however. Set that to false to get rid of the press and hold right click behavior. I tested this on Windows 7 with .NET 4.0, but the property is available from .NET 3.0.
<RepeatButton Stylus.IsPressAndHoldEnabled="false" ... />
There is also a blogpost here that provides a code sample for a similar disabling of press and hold at window level. But with this in place, the PreviewTouchDown and TouchDown events will not be raised as soon as the finger touches the screen (which would be necessary for a RepeatButton I guess), only later. Read the 'Remarks' on this msdn page.
You can override the OnPreviewMouseRightButtonDown on the Window and set Handled to true. You also need to handle OnPreviewMouseRightButtonUp (thanks to Vitalij for pointing this out)
That should do the trick.
We have a very strange behaviour of a WPF application. Sometimes (not very ofen), some parts of the user interface are simply not painted.
Just recently the save button and a text box on the configuration view didn't show up. Even more strange is that after a relogin, what results in a new view instance, the problem is still present.
Sometimes it helps to hover the mouse over the position where the missing controls usually are to get them visible. But switching the tab page and then back to the original one with the missing controls they are all missing again. Other controls won't show up by hoovering the mouse over them.
Another problem is that dialogs are sometimes screwed up. Parts of the dialog are displaced vertically. But when e.g. a text box inside the dialog gets the focus, it is painted correctly while the rest of the dialog stays displaced.
I don't have the slightest clue what causes this problem. Any idea is welcome.
[Edit 1] So far we have seen this always on Windows XP. Windows 7 seems to be Ok. Also switching to Software-Rendering seems to fix the problem on Windows XP but I'm not sure on this.
The problem was solved by switching the RenderMode to SoftwareOnly. It seems to be a .NET 4 issue when running on Windows XP:
public class MyWindow : Window
{
protected void SetSoftwareRendering()
{
System.Windows.Interop.HwndSource hwndSource = PresentationSource.FromVisual( this ) as System.Windows.Interop.HwndSource;
System.Windows.Interop.HwndTarget hwndTarget = hwndSource.CompositionTarget;
hwndTarget.RenderMode = System.Windows.Interop.RenderMode.SoftwareOnly;
}
}
Alternatively one can write
System.Windows.Media.RenderOptions.ProcessRenderMode = System.Windows.Interop.RenderMode.SoftwareOnly;
All windows are inherited from MyWindow and can decide wether or not they want the software rendering. Currently we don't use this flexibility and have it enabled on all instances.
If this happens in other WPF applications too it might be your hardware, driver, OS or .NET software.
If not, the only option is to try and reproduce in a minimal case and on several machines.
Are you able to make a minimal version that has the problem en post the code?
What could be the reasons for the Main application form not to be shown in TaskBar?
ShowInTaskbar property is set to "true", but form doesn't show itself there if after running the application and before the Main form appears I switch to some other window. Form exists, but until I minimize apps that are above to make it visible, it won't show in Taskbar.
UPDATE. Form does not have an Owner.
I've added form.Activate() after form.Show(). Now it always jumps out when completely loaded, and doesn't get lost under some other screens.
Though it is not a solution, but a crutch, responses are welcome anyway.
Check if your main form has a Parent defined or an Owner. In either case that would exclude it from being in the task bar in its own right. Also worth trying TopMost=true.
I had the same issue with one project I wrote.
No icon showing in the Taskbar unless I forced Windows to refresh it.
It was a call to
this.MinimumSize = new Size(wid, len);
In the Form_Load that was the issue.
I had a similar issue when the program was run from an installer (InstallMate in my case). I eventually pinned the problem down to changing the form's title text (Text) in the Form1_Load() method. When I moved that title changing text to just below the InitializeComponent(); bit, the problem went away.
I hope this can help someone else, despite the specificness of my circumstances.
I had the same issue as #deegee where setting MinimumSize in the Form Load causing the non display in the Taskbar. I fixed the issue with setting the Form Visible to False then to True.