This function is like the "always on top", it is something like always occupy the right most area.
I wrote a software that the software will pull some messages from server periodically, so I want to put it into the right-most area of the screen, and never be overwriten by other windows unless the user press the minimize button.
So it means the other windows, even the maximize button is pressed, will only occupy the left side of the screen(the space that not be occupied by my software).
Is it achievable in MS Windows?
Sounds like the support for Application Desktop Toolbar is what you want:
An application desktop toolbar (also called an appbar) is a window that is similar to the Windows taskbar. It is anchored to an edge of the screen, and it typically contains buttons that give the user quick access to other applications and windows. The system prevents other applications from using the desktop area used by an appbar. Any number of appbars can exist on the desktop at any given time.
The best you can do is to make your window "always on top". You can't reserve part of the desktop exclusively for your application.
Related
I'm writing a HUD style application (just text, zero user interaction) and I want my text / water marks to always be visible regardless of other apps on the system.
I made myself a WPF popup and topmost but if other applications come along that want to be topmost as well they seem to supersede mine.
Is there win32 support to override this and effectively watermark system / appplication wide?
Nope. From Raymond Chen's blog: What if two programs tried to do this?
"How do I create a window that is never covered by any other windows,
not even other topmost windows?"
Imagine if this were possible and imagine if two programs did this.
Program A creates a window that is "super-topmost" and so does Program B.
Now the user drags the two windows so that they overlap. What happens?
You've created yourself a logical impossibility. One of those two windows
must be above the other, contradicting the imaginary "super-topmost" feature.
I'd like to create an app that I can dock to my screen such that when other windows are maximized they neither obscure my app, nor are they hidden behind my app. "Always on top" is not good enough since other windows can still hide behind it. It should effectively reduce the available size of my monitor and behave like a toolbar. Full screen apps should obscure my "toolbar".
So, eg, if I dock my app to the right side of my 1920 x 1080 monitor and size it to be 200px wide, the largest window I can have open on that monitor would be 1720 x 1080 (or shorter if it is the main monitor with the Windows task bar).
I remember doing this in Windows XP with just an HTML file and some ActiveX controls. XP had some shortcut to use that file as a "toolbar". I can't remember exactly how I did it now.
I haven't seen anything exactly like this on Windows 7. If the HTML hack is still possible (I believe it isn't) that would be ok, but I'd rather create a native, compiled application. Is it possible?
There's an article on CodeProject which seems to provide a sample for what you're looking for. The project is to create a desktop-toolbar which remains docked beside other windows on the screen, even if they're maximized.
During this article we will develop a class named ApplicationDesktopToolbar. This class inherits
System.Windows.Forms.Form. So when we want to make our application to
behave like an appbar all we need to do is inherit from
ApplicationDesktopToolbar instead of System.Windows.Forms.Form.
Original article author: Arik Poznanski
I am trying to create a parent WPF/surface application which will host multiple WPF/surface applications. I am looking for some pointers of how to implement such functionality. Was reading http://msdn.microsoft.com/en-us/library/ms742522.aspx but it talks about hosting Win32 content in WPF and vice versa.
My idea is to have something similar to MDI forms where you have a main form and you can instantiate multiple child forms.
In my case, these would be different applications which will be launched using a config file and loaded within the main application.
Also, since is there a way to ensure that the main window's process memory is not hogged by the child process initiated.
Edit:
The host application will launch different applications based on what user selects. One can say its like an application launcher which are build on WPF/Surface touch SDK. Now once the application is launched the launcher goes in the background(except showing small button to bring it forward again at some point later) and when the user ends the current application launcher comes back again in foreground. The only interaction i feel which is necessary is knowing the launched application is terminated or invoking applications in a limited screen area. If someone has seen the Microsoft surface application launcher, even when the application is launched there are corner buttons which bring the app launcher to foreground.
I would first look at using Microsoft Prism, specifically the Modularity namespace.
Except for the "different applications" part, it sounds like a classic case for MVVM. Are these "different applications" actually separate applications, or could they simply be separate projects within the same application? That may simplify the choice of presentation.
I suppose you could still have a View called "Host" that presents a different app.
Of course, WPF doesn't have the concept of MDI, but you can open multiple, non-modal windows.
It really depends on what you mean by "hosting". Does the main window need to somehow handle and/or interact with the other applications, or is it just a launching pad for other applications?
I followed this approach to solve this problem. The launcher was not hosting the application within itself but would launch a new application and hide itself.
Steps I followed:
The main launcher application will run in Kiosk mode i.e always on top/no option to close by capturing the close event/No instance shown in taskbar/no title bar/killing the explorer.exe/hiding the taskbar.
The launcher populates a horizontal listbox (data templated for UI) which lets occupied main center area of screen and can be scrolled either ways.
When user selected an item on listbox, click/tap event a separate process is launched with launcher window's visibility set to hidden and a small button(basically a window with just a button inside and size set to height/width of button) created on the either corner of the screen with always on top option.
The functionality of button is to minimize the current working application and set visibility of launcher back to visible and setting the focus to this window.
Since the process is launched by launcher, i trap the close event for the launched window to know user ended the application and then again pop up the launcher back.
When I set focus on a text box, on a forms load event in Windows Mobile 5.0, the Windows tool bar appears even though my form is maximized.
When I do not set the focus on the text box the form opens maximized. I do not want the windows tool bar appearing.
How do I prevent this from happening?
TThe start bar in WinMo is actually not part of your app - it is a separate process managed by the Shell and it really wants to always be on top. Trying to get your app above it goes against the design goals of WinMo (though it's a common thing to want to do).
I'd recommend doing some searching and reading on "kiosk mode" to garner what knowledge you can from others who have been down this road, but what you're seeing is that the StartBar is getting set topmost.
Raffaelle Limosani has a pretty decent blog entry that covers kiosk mode, so it's a good place to start (take a look at the other blogs he links to as well).
The toolbar at the top is actually a separate window, and it has a habit of appearing when not wanted over top of a full-screen ("kiosk" mode) app. For example, if you ShowDialog a second full-screen window from the first, the Start window flickers up for a split second before going away.
The only way I ever found of dealing with it was to hack into the API and actually make the Start window hidden while my application was open. This is a big potential problem, because if your app crashes without making the Start window visible again, it will stay invisible until you reset the device (or run you app again successfully).
I'd advice against doing this unless you absolutely have to. As ctacke points out, this would be an example of an app not playing nicely with Windows Mobile.
How would one go about displaying taskbar notifications?
I want to write an app that periodically displays a flash card esque notification, the intention is to see if a 5 second or so distraction every hour can help with language learning.
In .NET you can use the Notification Icon to place a notification in the system tray.
For the application you describe, I probably wouldn't use a notification icon or taskbar icon. You'll likely need a larger window displayed, with larger font.
I'd open a frameless window (possibly faded or scrolled into view) that sits in the lower-left of the desktop. (Although of course remember that not everyone has the taskbar at the bottom of the screen).
As an example, look at what Outlook or many RSS readers do to notify of new messages - this feature is commonly called a "toast" pop-up.