My company makes a product that includes both a display and a USB input device. Right now they show up as two separate icons in Devices and Printers, and we'd obviously like them to be exposed as one.
According to the documentation at MSDN, the way to do this is to provide a ContainerID through one means or another, but display devices are not mentioned at all. Does anyone have an idea how to manage the ContainerID of a display device?
According to someone at Microsoft, this is currently not possible:
http://www.osronline.com/showthread.cfm?link=195254
http://blogs.technet.com/b/askperf/archive/2010/03/02/windows-7-where-are-my-printers.aspx
fix. but it's aesthetic anyway, if you right-click the printer and hover over properties, you can choose props for each individual printer, and they're seperately selectable in printer choice drop-downs, such as in word > file/ribbon > Print [choose either & go].
But either way, if you're after a fix, the link is above.
Related
My aim is to display a little overlay, a flag icon, for the chosen keyboard layout, etc. at the exact location where one would type something, as to help the user immediately see which input layout is being used (for example US vs JP layout).
I would like to do this not per application, but globally.
My first attempt to do this was to listen for various Microsoft Windows specific events, when the caret changes, and so on, but apps like Slack for example work differently than native Windows apps so this is hard to do.
My other idea is to track the caret's blinking motion over the screen (taking screenshots periodically and detecting where the caret is blinking).
Not sure how sound these ideas are, but this question is attempt the find the best possible solution to do this.
Thank you for all your inputs.
A_CaretX and A_CaretY in autohotkey(V1 version) maybe help you
see https://www.autohotkey.com/docs/Variables.htm#misc
I am trying to setup individual window sharing for a project in Unity for Windows. The way I'm currently going about doing this is by using EnumWindows(), IsVisableWindow(), and GetWindowText() to create a dictionary of window titles and handles, then calling StartScreeCapturebyWindowId() to share the selected window.
This works relatively well for most process; the window of the process and only the window of the process is streamed. However, for certain programs (like Google Chrome, Discord, and Windows Photos) the captured area is set correctly, but overlapping windows are not culled out.
Does anyone know what could be causing this problem? Is there something wrong with the way I'm grabbing the handles for these windows? Or is there something about starting a screen capture that I am missing?
You certainly did the correct things. However, you also hit the limitation to the Windows part of the SDK. To understand this better, the set of programs are UWP applications. They have different ways to share the visible pixels. Previously version of Agora SDK could not even show the window. Starting from 3.0.1, the SDK uses Rectangle cutting method to get the window display. You may further read the online documentation about that API here.
There isn't much Agora can do for the near term. So you will just need to deal with the user experience (e.g. by warning them) or look at solutions like using Web SDK instead.
I have a potential requirement of modifying the Windows 10 Start Menu structure. I know that you can customize the groups and tiles: https://blogs.technet.microsoft.com/deploymentguys/2016/03/07/windows-10-start-layout-customization/
My question is if there is any possible way (through API or any other option) that allows to, instead of only pinning windows desktop applications, display your custom code.
Example: we have a group called My work which pins windows applications, but we also have a group called Discover which displays custom code, not windows 10 apps.
I think it is not achievable, but want to give it a try and ask the community. Thanks a lot in advance!
Modify start menu should not be a feature of common UWP development. The start menu should only be controlled by customer themselves. So it's not possible for you to think about develop this kind of feature.
And as you've already see that OEM can modify OEM group. Actually you can find related info from here.
So we're re-designing a desktop application so that it's also usable with thye Touch Interface with Windows 7. We've consulted the UX guidelines.
For some part of the UI, there are toolbox icons that are disabled because of some arcane rules (the software communicates with a hardware device). We disable the actions that aren't applicable (because of some condition) and let the user hover the mouse on the tool icon to see the tooltip explanation on why that tool is disabled.
Since there is no "hover" for the touch interface (windows 7, iphone, ..) what is a better pattern/model for this?
Thanks!
Not an official solution but here's how I'll approach this until a better solution is available:
Make the item look disabled but still be clickable.
Add an overlay icon (of a question or similar) so it looks more than just disabled.
When clicked, display the message that would have been in the tooltip. Preferably in a non modal way and that doesn't require acknowledgement.
One option is to leave the control enabled and show a message when it is clicked to say why it won't do anything. However as stated in 'Disabled Menus Are Usable' this throws away valuable information for an experienced user (although this is less of an issue for icons than menus as there are usually less icons to go through than menus).
Another possibility is to provide a control like the click for help tools that were popular a few years ago. The user would first click on the 'why is this disabled' control, then click on the control that is disabled. This is however a rather clunky solution.
Another problem with toolbox icons on a touch interface is that the tooltip text is often essential as it is often impossible to convey complex/domain-specific actions with an icon. i would imagine many users on a touch only device will just use the menus instead as they can work out what they will do.
Up to now I been using the pda emulator in visual studios 2008 (I am using windows mobile 6.1 professional sdk).
So I just dragged and dropped most of my GUI components into the form. In one instance I made a panel then in this panel I dynamically generated labels in it with certain location positions.
I then put it on my Hp PAQ 110 Classic pda and it looked fine and everything. Then I was looking through the emulators one of them was called professional square. So I decided to run it and when it ran my program it looked like crap.
I had missing labels, missing controls and it just looked horrible.
I thought maybe it would like do some resizing for me but it seems to either did a shitty job or it does not do it at all.
So how do you make a GUI that will work well on all mobile phones(or at least the vast majority of them).
Is there like X number of types of mobile phones? Like the emulator emulates a pda and it works on my HP one so I am assuming that all window mobile device pdas have the same screen size.
Then the next question is how do you make the controls position properly from one device to another? I heard of people using XML files that have all the location position, sizes and etc that they call up and I guess essentially generate the GUI dynamically based on the information in XML.
But I could not find any examples how the XML file would look like, how to detect what phone type it is so that I could call up the right node of the file for that phone.
I am not sure if there are any other ways but this seems better then a set of GUI forms for each one.
Also would it be recommended to have most things in a panel so that way even if the stuff is bigger you can at least turn auto scrolling on.
thanks
I spent a good amount of time looking at different solutions for this problem (see my question here as well) and ended up with a pragmatic approach - consistent use of docking. You have to restrict yourself to the least common denominator, i.e. the lowest resolution you want to support, in terms of how much you can fit on the screen. The good news was that grids always use the entire available real estate, and my forms flow correctly on all devices and the screens don't look like they are broken.
This is far from being an easy task. You can follow some guidelines, but the only thing that will actually work is to always test the User Interface in all possible screen resolutions. Emulators are a good way to start, however it will be better to have an actual device. Some things like font sizes and text readability can only be tested in a real device. So, these are my advices:
Try to use docking for positioning your controls.
You need to be able to handle orientation changes correctly. Using docking helps, but again you always need to test in different screen resolutions.
At some point you will find out that it is inevitable to detect the screen size and adapt the User Interface dynamically. I don't agree that you should restrict yourself to only display what can fit in the smallest screen. A professional application should adapt itself to the available screen size and take full advantage of it.
Structure your application so that it is easy to support new screen resolutions. Make the main User Interface code screen size agnostic. Make it get all information about dynamic resizing - positioning from a configuration class. This way you only need to enhance a single item in your code in order to support a new screen resolution.
And of course:
Test in all possible screen resolutions. After even a minor change to the User Interface, retest.
Eventhough the above posts where helpful this video I found solves all my problems and you don't have to develop for the the lowest screen.
http://www.microsoft.com/events/series/detail/webcastdetails.aspx?seriesid=86&webcastid=5112