I have a wxwidgets (2.8) app that works great on Linux but on Windows the combo boxes are suddenly read-only. What do I need to do to get it to allow typing on Windows too? I process text events but I can't get characters typed to be recognized. Is there anything special on Windows that needs to be done?
In essence I am trying to use the combo box as a filtering select (like an autocomplete) and it works fine on Linux. Is something seriously wrong here on Windows?
Now, I am using wxperl and I have looked at the documentation, but when I type in the combo box on Linux/GTK it works but on Windows nothing appears. Am I missing a styling option or something? What differences in underlying widgets can account for this?
EDIT On further investigation they don't appear to be fully read only, but the text event seems to remove the text in the box, so this appears to be an issue with event handling. In essence, how do I process a text event without losing the value?
I found the problem. The issue is that Clear clears the value of the combo box on Windows but not on GTK. The solutions to fix the problem are not as readily portable across platforms as I would like but that is not that unexpected.
Related
I am making a WPF application that is to be used on a kiosk with no hardware keyboard. Currently we are using a third party on-screen keyboard, but the Windows 8 version is a lot better and we are thinking of switching to it.
So my question is simply if it is possible to show/hide it as well as show a numeric only version using c#.
Thanks!
David
From this source:
There is no direct way to control the touch keyboard programmatically.
Requiring the user to set the focus rather than the program is a
deliberate design decision to prevent UI churn.
See Input Hosting Manager and the Touch Keyboard for more information
on how and why this works. The User-driven invocation section of that
document explains the specific behavior you are asking about.
But, once the user touches an input control, the soft keyboard will automatically be displayed (with no extra coding needed).
Finally, to address your question on a numeric-only version of a keyboard, you may propose a different keyboard layout using InputScope on a TextBox. The different input scopes are enumerated here, but one of them is "Number".
I've published a sample on how to trigger the touch keyboard in WPF applications when a user clicks into a Textbox, its here:
http://code.msdn.microsoft.com/Enabling-Windows-8-Touch-7fb4e6de
I've been working on this sample for many months and am glad to finally contribute it to our community. Please let me know if there are any questions, suggestions, problems, etc in the sample Q&A pane
Also note that while demonstrate how to "show" the keyboard, i'm not sure how to dismiss it programmatically at this point so its important to test any actual implementation to ensure its a good experience. For example some controls like Button will dismiss the keyboard when they get focus from a TextBox, but certain ones like Checkbox will not and I demonstrate that in my sample.
I'm using a DocumentViewer to view a FixedDocument and on 2 machines (out of over 500) the document viewer does not show the document.
Edit: ok, it's not a bug in WPF and the DocumentViewer control works perfectly, I'm leaving this question unchanged in case someone else hits the same problem, see my answer for the solution.
The document viewer is using a custom ControlTemplate based on this MSDN sample (mostly to remove the search box)
The toolbar, scrollbar and background all show up but the scrollbar is disabled and the content are is blank (background color)
I'm sure the document is ok because printing the document works.
I don't have any access to those machines, one of them is running Vista in what looks like a standard configuration, I don't even know what version of Window the other one is running.
The application is targeting .net 3.5
Did anyone here ever had a similar problem? do you have any idea what's causing it?
Thanks.
Here's what happened, I was using PrintDialog to get the default printer's paper size in order to create the FixedDocument, according to the docs and all my tests you can use PrintDialog without actually opening the dialog or actually printing anything and everything works just fine.
But on some computers (probably due to misbehaving printer drivers) this doesn't work, so on those computers the returned paper size was incorrect, I actually don't know it the size was too small or two big but it caused the code generating the FixedDocument to fail some internal sanity check and produce and empty document - that the DocumentViewer control then displayed correctly by showing nothing.
When I try to use Morae Manager 3.0 to run a Screen Text search on a recording of our prototype (coded in WPF, .NET version 3.5 SP1), the only things that come up are the window titles. We are using Windows XP.
Even when I search for something that is editable, like text typed into a text box, it does not come up.
Screen text for things outside the prototype (e.g. desktop icons) still comes up perfectly.
I contacted TechSmith support on two separate occassions and both times the reply I got was it must be an issue with our technology, since the screen text search does work for other things, and that the support people are not developers and thus do not know what might be causing this.
Does anyone know:
what precisely might be causing this -- e.g. does WPF's rendering engine bypass some sort of Windows layer where Morae looks for text (please forgive me for any errors in terminology)
if there is anything I can tweak in the prototype to fix it
how I can get through to someone at TechSmith who knows the answers to 1. and 2.
P.S. Morae is a wonderful product and we've usually had great support from TechSmith. We are only having problems with this one little thing, and one can hardly blame Morae for not being compatible with something as new as WPF.
I have no idea what Morae is or how it works, but one big difference between WPF and for example WinForms is the following, copied from here:
When you create a WPF Window, WPF
creates a top-level HWND, and uses an
HwndSource to put the Window and its
WPF content inside the HWND. The rest
of your WPF content in the application
shares that singular HWND.
If Morae depends on HWNDs to find texts on the screen, this could explain why it can not find the text box. In contrast, i believe in WinForms every control (button, textbox) has its own HWND.
I'm having some trouble with Visual Studio 2008 on my Windows XP SP2 laptop.
What happens is that when I start a program with a few textboxes and stuff like that, the boxes are see-through. I can litteraly see through them and see what's on the underlaying screen. Like if I only have this Form showing and behind that my wallpaper, I can see my wallpaper through the Textbox, ComboBox, even through the small cracks between various elements.
i've searched the web but haven't encountered info on this yet. Does anybody know what might be causing this and how to solve it? I'm in the process of trying to see how the text in my TextBoxes is parsed, but I can't since I can't even enter anything. I click on the textbox and I'm focused on the desktop...
Hmmm... I'm not sure about this, but check the "Transparency" property of your main form. That's all I can think that it might be as of now...
Update: I meant the "Opacity" property, sorry.
Update 2: No, never mind, sorry. Right-click the "TransparencyKey" property, and press Reset to set it back to default.
Check TransparencyKey, Opacity and maybe TransparencyMask?
I've got an issue with a WPF application that I'm writing. The app needs to be able to keep focus at all times. The computer it's running on is a highly specialized machine with the only purpose of running this application.
There is no keyboard connected to the machine (it has a touch screen), so the only thing that can steal focus is windows own "needy windows", such as windows update etc.
How can I make it so that my app retains focus at all times? Is it possible to make the entire app modal?
EDIT:
Thank you both for your answers. I think I'll end up using Topsmost for now, but I'll definitely check out the source of babysmash as that application works exactly the way I want mine to, in regards to the way it handles focus.
Look at the source of BabySmash. It is specifically designed to keep focus even under quite bizar circumstances. (It is a program designed to run at full screen and let babys smash on a keyboard - so quite some focus went into capturing all kinds of weird keyboard combinations and alert messages).
I would use
<Window ... Topmost="True">
i xaml. But maybe this is not what you are looking for