I've created a Windows CE 5.0 application which runs on a handheld scanner. The scanner has its own (hardware) keypad and almost all input comes from the scanning unit.
Unfortunately whenever the text box receiving the scanned characters is focused the input panel appears at the bottom of the screen, blocking almost a third of the screen space.
Is it possible to deactivate it in my form or in the whole application?
If you're not doing it manually via the InputPanel control, then I assume you have aygshell in the image and they are being rendered with a WC_SIPPREF control. I'm not certain if you can remove that control manually - I've never tried. There may be an agshell function that will allow you to disable/remove it, or maybe some work with the InputPanel for your app can remove it.
You may also want to see this blog entry for a bit more detail.
That last time I worked with CE was back when it was called pocketpc 2002 (I still have my old iPaq 3870 - one of the first devices with bluetooth and one of the last without wifi), but at that time the simplest way around this was to set the device to use a hand-writing recognition mode that didn't pop up anything. That may or may not be an option for you and things may have improved since then.
Related
I'm working on a WPF app where i want to display the built-in windows 7 onscreen keyboard in a 'always there' manner. So i want to:
Move it to a particular location
Set it to a certain width and height
Remove the caption/titlebar so the user can't move it around or close it
Remove that abilty to resize it (or any other user adjustments for that matter).
I've tried all the typical API functions (MoveWindow, SetWindowPos, SetWindowLong, etc...) but it refuses to do anything. Code currently works with all other processes and apps (such as internet explorer and the command prompt); it's almost as if the api calls don't apply to the osk, or that it's 'locked'. What am i missing? Thanks in advance.
I checked with Spy++ and the On-Screen Keyboard uses something called "DirectUIHWND". You may wish to look into DirectUIHWND APIs.
A possibly helpful link:
http://www.codeproject.com/KB/COM/cominterfacehookingpart.aspx
In addition, some people have warned that DirectUI is undocumented.
Users complain that when they have several minimized windows in MDI container it's impossible to distinguish them unless they resore each. I wonder if it's possible to make minimized window a little bit wider so the text in the caption can contain 6 characters?
Thanks in advance!
No, this is not possible. Windows determines the width of a minimized window using the current system parameters, and there's no way to change this dynamically for a single application without changing the values across the entire system.
Specifically, the default size of all minimized windows is 160x31. In a MDI application, you actually get to see this size because the window is minimized into its MDI host, rather than into the Windows taskbar. Raymond Chen (a developer on the Windows Shell team at Microsoft) published a couple of blog entries a while back that explain why this particular size was chosen, and what it means. The first is available here: Why do minimized windows have an apparent size of 160x31? And the second follow-up entry can be read here: No, really, why is it 160x31? As he explains in that second post:
The width of the miniature title bar is determined by the iWidth member of MINIMIZEDMETRICS structure. You can retrieve and change this structure with the help of the SystemParametersInfo function. (Use the SPI_GETMINIMIZEDMETRICS and SPI_SETMINIMIZEDMETRICS flags, respectively.) Some people will mention the MinWidth registry value, but those people are wrong. Notice, for example, that messing with MinWidth requires a logoff cycle, whereas using SPI_SETMINIMIZEDMETRICS takes effect immediately. That's because SPI_SETMINIMIZEDMETRICS updates the internal state variables, whereas whacking the registry just change a value in a database that nobody pays attention to once you've logged on.
What about the height? That's just the height of a caption bar, which you can adjust from the Appearance tab of the Display control panel. (Programmatically, you can use that helpful SystemParametersInfo function, this time using the iCaptionHeight member of the NONCLIENTMETRICS structure.)
Since I doubt your users really want you messing with their default system parameters by P/Invoking the SystemParametersInfo function, you aren't left with a whole lot of options. My recommendation, especially if they're working with a single window at a time and leaving the others minimized, is to switch to an alternative interface. The intention of MDI was to allow users to tile or cascade multiple windows so that they could see more than one at a time. Since it sounds like that's not the typical use case, you might both be better served by switching the application to use tabs instead. This is often called a tabbed document interface (TDI), a somewhat more modern implementation of the old multiple document interface (MDI). It's become quite popular over the years; check out the Wikipedia article.
[Although this post is 11 years old, i'm trying...:
I'm facing an issue with in-app minimized windows, which are broken on my Windows11 (certainly by a software, but I don't know which one...). Those in-app minimized windows are much more narrower that it should be. Instead of having the minimized title bar containing title and 3 buttons, I can only see the close button. You said here it wasn't possible to change this size for a unique software, but I assume you know(knew) where to change it for the whole system? Here is a capture of the issue in ultraedit 1 and here in 3dsMax for example 2
To those who have the same problem as me, I found the solution:
(win+r) regedit
HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics
add the string value "MinWidth".
Change the string value named "MinWidth". Set its value using the following formula:
-15*width in pixels
For me, acceptable one was -3300
Little drawback: It also changes size of the minimized windows in the taskbar (make them much wider when there is a few of them in taskbar)
So, here's a weird question: Is there a way for me to disable the menu you get when pressing the "C:\" button at the top left of the console?
I am making a game, for fun, but it would take away alot of the fun if players were able to paste words into the command-line.
I haven't found any topics about it, so I was wondering if anyone has an idea on how to get this done, or atleast a work-around.
Thanks in advance!
Edit: Would a simple reg-ex for any ^ character work? Or does the console not use ^C and ^V?
a) Use GetConsoleWindow to get window handle; use subclassing and hooks to filter mouse and keyboard events. Though this approach probably has a lot of hidden obstacles, because of Windows console implementation specifics.
b) Use timing analysis. Measure time interval between keystrokes and ignore input if this interval is unreasonably short. You may have to experiment to find the criterion that works best. Maybe it's better to measure input duration of entrie word, not inter-character intervals.
Note that pasting text to Windows console is implemented via keyboard input simulation, i.e. when you paste something to a console, the console application observes a sequence of key-down/key-up events.
I'm not sure if the console supports pasting via a keyboard combo, you can paste either via the menu or just right clicking in the console (this depends on how the console is set up though).
I'd suggest that a better solution would be to create a winforms app instead where you can control the input/output easier than in a console app.
Otherwise, one workaround might be to call Clipboard.Clear every 100ms or so to make sure that they'll never have time to copy and paste anything until you've cleared it out, but this could of course upset and/or confuse the users if they have your application running in the background and are trying to do some work in some other software.
I want to create an alarm app for myself. On certain conditions (i need to poll websites) i want my app to inform me and make it HARD TO MISS. So i can take appropriate action or ignore it if i need to do something else.
I wrote a test app and using a BalloonTip (ShowBalloonTip with notifyIcon) isnt great. One of my previous apps brings the window in front of you and does a MessageBox however that doesnt always work or work well (if i somehow miss it or accidentally forget to click ok no futher messages will occur).
What are your suggestions?
You could also make it a system tray application and change the icon out if there is something which requires attention, a la a messenger application. That may not be "hard to miss" but I am trained (for better or worse) to look down at the icon tray when I see something blinking.
Where I work, we have a TimeTracker application (built in house) with which developers are supposed to log what we worked on and when. I am notorious for not using it. So, I wrote my own (Windows Forms) version for my own use which, every hour opens up and takes over my screen:
It is a frameless dialog which consumes the entire screen.
TopMost = True.
On resize, it sets WindowsState = Normal and resizes to fill the screen.
While it is open, it polls for taskmgr.exe and procexp.exe and kills them if found.
It disables the start menu to prevent cmd.exe commands from the menu in Windows 7.
The only way to close it is to enter a log, only then is the OK button shown!
So far, it's working out well - no one has been able to break it!
My less drastic suggestion would be to have a notification which pops up momentarily above the system tray. After a second or two, fade it out. Keep showing the notification every 30 seconds or so until it is dismissed.
Always-on-top window in the corner of the screen?
You could always set your window to be a top most window, make it full screen, and activate it. It would be very, very hard to miss...
Granted, it would also be very annoying, and not something I'd do to other users...
My "real" suggestion would be to use sound along with standard notification methods if this is going to be used by other people, as that's an easy way to grab attention without necessarily killing their workflow. A modeless window that appears in a corner of the screen, especially if combined with sound and color, can be very effective to grab attention.
The industry has been adopting these ambient orb devices and variations of it when such a hard-to-miss notification is required. It is used for tracking the stock-market and for broken-daily-builds.
http://www.ambientdevices.com/cat/orb/MAN_Ambient%20Orb_3-23-03.pdf
Regards
Currently our software is running on AIX Unix machines, but we use Windows boxes running Exceed to display the UI in X-windows. I'm writing a Windows application ( modernizing the UI in C# ), but some of the legacy windows still need to be displayed in Exceed. When a user clicks a button on my windows application, it sends a message to the Unix server which displays the X-window. My problem is that these X-windows are not getting focus, so they are popping up BEHIND all of my .NET windows/forms.
A user of this software can easily have 5+ windows forms open at any given time, so it is a big inconvenience if every time they want to display a legacy X-window, they have to minimise all of the .NET windows. What is the best way for me to solve this? Is there a way for me to give Exceed focus so that it brings the X-window to the top? I tried using Application.OpenForms, but calling .SendToBack() on each form didn't help me.
If the pop-up windows are coming from a process other than the Windows app which you're creating, you'll probably need to resort to a hack. Microsoft put code into WinXP to prevent apps from being able to throw their windows in front of everything, unless it's part of the app the user is working on. To do this, you need to monkey with the ForegroundLockTimeout registry value, and the Windows APIs to pull a window to the front.
More info:
http://social.msdn.microsoft.com/forums/en-US/winforms/thread/54826e98-9faa-4457-ba1d-b645af88170b/ (The last entry contains the conclusion, but you'll need to read some of the previous entries. I also suggest you set the ForegroundLockTimeout to zero, do the switch, then set ForegroundLockTimeout back to its previous value.)