Is it possible to change a value of a WinRT control in another application?
I am using a Windows Surface Pro 2, which uses Windows 8.1. this OS has a text prediction feature which requires the TextBox.IsTextPredictionEnabled property to be set to true. If this is set to false, then it will not use the text prediction.
Unfortunately for me, there are instances where the application developer thought it prudent to turn this feature off (default is on) and I disagree. I would like to change this. Is there a way?
No. The applications on top of WinRT are heavily sandboxed, so there is no direct way to affect other applications than yours.
As Euphoric said, there is no direct way to do that.
If I needed to change a properties (I'm talking about our own apps), maybe I can try to create a text file and read it with the other app, so with a few if condition I can change values by that text file. But both of your applications should be updated. If they are not our application there is no way to do that.
Related
I'm developing a Windows 10 Universal app (UWP).
Is it possible to set application as TopMost (always on top)? Like WPF or Winforms (TopMost property).
Thanks
A feature called CompactOverlay mode was added in the Creators Update that supports this type of functionality. When an app window enters compact overlay mode it’ll be shown above other windows so it won’t get blocked. This allows users to continue to keep an eye on your app's content even when they are working with something else. The canonical example of an app taking advantage of this feature is a media player or a video chat app.
A blog post describing the feature can be found here
https://blogs.msdn.microsoft.com/universal-windows-app-model/2017/02/11/compactoverlay-mode-aka-picture-in-picture/
Short answer is no, there is no way as of today to make the application modal.
There is a petition going around asking for this functionality, which was requested last December but given the amount of votes it got (35 at the time this answer was written), it doesn't look like it will be taken into consideration anytime soon.
As mentioned in the comments, this functionality would be PC only so even if it was added, my assumption would be that it wouldn't work outside of the PC mode (so no tablet, mobile or surface family device support).
It's not possible UWP apps have some restrictions compared with WPF of Win32 apps(classic apps).
With uwp apps you need enable some capabilities to do something special in your app as you can see in the link uwp apps need ask for permission or they can't access or modify files directly.
https://msdn.microsoft.com/en-us/library/windows/apps/mt270968.aspx
Best Regards
I currently have an application for personal use, which I also take to work. I use a custom windows 8 theme on my computer at home and my application is designed around this theme. So when I open my application at work, or anywhere else for that matter, it obviously looks nothing like expected and certain text is unreadable because the colors simply do not match.
My question is, if there's a library or feature which I've missed, with which I can apply this windows theme to my application without installing the theme on the system?
If not, is this possible with WPF, without too much trouble?
Thanks!
I'm working in a WinForms project.
I have a dark theme activated in Windows and this is a default combobox when it's focused:
And this is when it has no focus:
An horrible and insane white border appears when the control lost focus, I want to avoid that without disabling XP Styles in the project.
I know that maybe the only way is inheriting the control to make my own, the problem is I don't know what I need to do with the control, maybe changing a setstyle property or I don't know.
I think you're trying to solve a problem that isn't in the scope of your application. Isn't this just an issue with the theme in question you are using?
Windows has many themes. The major themes still supported are Classic (pre-XP), Luna (XP), Aero (Vista/Win7), and Modern (Windows 8). All of these can be customized to create an infinite number of possible scenarios.
Most Windows Forms controls are based on Win32 controls which are drawn by the OS according to these system themes.
So you have to understand that on the machine you're testing on what you're seeing is going to vary a lot from what users of the application will see on different versions of Windows with different user preferences.
The simple fact is that if you use WinForms base controls you really should surrender control of the appearance to the OS as much as possible.
It's also widely accepted to create your own application theme that the user can't change or that they have to pick from a predetermined set of themes you have created. Examples of this include Google Chrome, iTunes, Winamp, etc. It is typically an awful lot of work to do this with simple Win32 controls unless you use something like WPF which makes it easier.
The important thing is that you can't really pick and choose which parts of your application to theme. If you want it to look consistent you either take responsibility for the entire theme yourself or follow the Windows standards of using system resource colors such as ControlText, ActiveBorder, AppWorkspace, etc.
I want to write a desktop gadget that will group icons on my desktop (using c# & WPF).
It will be a docked window that I can drag icons to it and they will stay their. Also there can be couple of this windows.
Where do I begin?
**I saw all the post here about it but I got lost. Please direct me to examples and explanation pages.
To expand on cevik's answer:
You cannot create WPF applications as gadgets BUT you have two options (which aren't as bad as you'd expect).
The reason is that widgets are composed mainly of web pages (HTML) and not executable (*.exe).
The problem of course is that WPF will only work with & produce executables.
First option - Windows API:
When I said you can't what I really meant is you can't use the Windows Vista/7 gadget platform to make your widgets.
However, you can always achieve a similar effect by using the Windows API.
The Windows API will let you do stuff to windows such as making them always on the background of other programs, which sounds to me like ~80% there (The rest would be stuff like making sure your window doesn't get re-sized or minimized, etc.).
Just as a note, the function you'd be looking for to make the window behind all other windows would be SetWindowPos (specifically the second parameter).
However make sure there isn't a library which already implements these stuff because it can be rather difficult (and consist of A LOT of surprises).
Second option - Silverlight
silverlight can be perceived as WPF for the web.
That obviously solves our problem.
However there is a cost to it, as expected.
Silverlight doesn't have all the features WPF has (possibly not all of the .NET framework as-well, not sure about that as I'm not really using it).
However it should be more than enough to get you by so you should definitely check it out.
Once you have your Silverlight application (and webpage) you'll have to create a manifest & install the gadget to your desktop. See here how to do so.
Maybe this will help you.
Template to easily get started on developing a Sideber Gadget using Silverlight 3.0 or 4.0 controls in C#.
I'm creating my first WPF application and I wanted to understand if there is some kind of best practice when mixing functionality from the System.Windows.Forms namespace.
Basically I want to have a popup window that opens by default in the bottom right hand corner of the users monitor.
I can't find a Screen.PrimaryScreen.Bounds equivalent in the WPF namespaces. The examples I have seen suggest referencing System.Windows.Forms in the WPF Application.
Which led me to the question, is this bad practice?, considering this reference isn't included by default.
I'm going to reference the WPF required resource in my existing windows forms application so that I can use this new WPF Window.
Is there anything wrong with this approach?
EDIT: I have actually found a property that returns information of the primary screen without referencing Windows Forms. The property is SystemParameters.WorkArea, my question of mixing references does still stand though.
Also you should consider resources and performance overheads as your application will have to load assemblies for both Windows Forms and WPF. It was mentioned several times within MSDN forums that WPF/Winforms interopping takes quite a lot of CPU cycles...
I don't think that referencing WinForms, when needed, is bad. Since WPF is still a relatively new technology, it just doesn't have complete feature parity with WinForms yet. For example, to my knowledge none of the standard Windows dialogs (Open File, Save File, Browse for Folder, etc.) have been implemented in WPF yet. The only way to display these in a WPF application is to use the WinForms version, or use P/Invoke to display the Win32 versions yourself. I go with the WinForms version personally, since they already took the trouble of wrapping the Win32 API.
My approach is to use WPF as much as possible, and only fallback to WinForms if WPF doesn't fill my needs. Hopefully over the next release or so of WPF this will become less and less necessary.