is it possible to render to Windows' desktop (to overwrite the wallpaper)?
It wouldn´t be Windows if this was not possible, so there must be a way.
One i found out is, to call "GetDC()" with 0. But this draws on the top -
so all windows are overwriten.
I just want to overwrite the background wallpaper.
Is it possible to render there with DirectX (should be possible if with GDI+)?
Any suggestions? :)
Thanks
R
It was possible before, MS killed the feature in Vista, and it no longer works.
AVS2 (visualization library in Winamp) used IDirectDrawSurface7::Blt with DDBLT_COLORFILL flag to present stuff to desktop, with some setup code before that.
Source code. What it did.
Related
As yolu may have noticed, MS introduced a modern kind of 'theming' in Windows 10 regarding the basic OS elements like start menu and taskbar. With newer versions, you can choose a 'light' theme as an alternative to the default black theme.
I was wondering if there is an API or hook to elegantly and (more importantly) efficiently check live for theme changes (Did not find anything in the MS docs regarding this, but often enough these gems are pretty hidden there IMHO).
Specific problem: When you have a desktop application with a system tray icon, chances are high that you designed it to be bright. Nearly all of the modern Windows icons feature such a style (simple and white, yielding good readability on the black taskbar). Now you can provide a different version in a darker style for the light theme, but how to notice when to apply this on the fly?
I'm aware of the registry key under HCU (Software/Microsoft/Windows/CurrentVersion/Themes/Personalize) which is what I'm utilizing right now. However, blindly checking for change every x milliseconds seems pretty awkward.
If no such thing is available, I'm also happy to hear some ideas for more efficient implementations of such a check.
Method 1： Use RegNotifyChangeKeyValue
Notifies the caller about changes to the attributes or contents of a
specified registry key.
Methon 2: Use WM_SETTINGCHANGE
Applications should send WM_SETTINGCHANGE to all top-level windows when they make changes to system parameters. (This message cannot be sent directly to a window.) To send the WM_SETTINGCHANGE message to all top-level windows, use the SendMessageTimeout function with the hwnd parameter set to HWND_BROADCAST.
I tend to use the second method, I have tried, and have been able to work successfully.
Minimum code example：
case WM_SETTINGCHANGE:
{
if (!lstrcmp(LPCTSTR(lParam), L"ImmersiveColorSet"))
{
//theme has been changed
}
}
Im trying to make a simple OSX-like dock application using Haxe 3.1.3. I cant seem to work out how to make the main application window transparent (no titlebars, borders etc), as well as ignoring mouse events except on the icons themselves. Ideally no taskbar item either, just a system tray item.
I believe Haxe Windows target uses SDL, and am pretty sure that SDL can support this kind of behaviour? Im not sure how Neko target is compiled, or handles this... Is there some flags I can set in the Haxe application.xml or something like that? Or is this just not possible with the Haxe Windows or Neko targets?
EDIT
I Discovered that the Waxe haxelib, which can be compiled with Neko, has a bunch of flags in the Window.hx file - https://github.com/nmehost/waxe/blob/cd9739e007ed10918166588faf2339d623b22fc4/wx/Window.hx
These include such options as FRAME_NO_TASKBAR and BORDER_DOUBLE, which both work when passed as arguments to the wx.Frame.create() function in the Simple.hx Waxe sample project.
It also includes the flag TRANSPARENT_WINDOW, but this appears to do nothing. No idea why the other flags are working, but the TRANSPARENT_WINDOW flag doesnt.
In Openfl (it's openfl which uses sdl and a xml project), you can remove the window border with this in your application.xml:
<window borderless="true"/>
But I don't know a way to move the window without borders.
relevant discussion:
http://www.openfl.org/forums/#!/general:moving-borderless-windows
I have a coworker who needs to have multiple versions of LabVIEW on his computer. He has a bad habit of opening LV2010 code in LV2013. LabVIEW doesn't warn that you are about to change all of the code to a new version of LabVIEW, and this breaks the code running on a test system on the production floor.
Here is my question: does anyone know of any kind of hack or legitimate method of changing the windows title bar for a single application? I would like to be able to change the color of the title bar only on LabVIEW 2013 from blue to red or something.
If this isn't possible, does anyone have an idea of how to distinguish one application from another that looks almost identical?
Thanks for any advice you have to give.
Well, the good news is that LabVIEW 2014 on will have the version number in their icon. That doesn't help your situation much, though. I'm not sure about changing the title bar, but I think I can help with your second question.
The icons for those versions are indistinguishable, however, the mass compile LabVIEW does when you open a project from an older version is a dead giveaway. You know LabVIEW is performing a mass compile if, while the project is loading, "Compiling:" appears where "Loading:" normally does. Close out of LabVIEW without saving and open the right version of LabVIEW. If he still goofs, there's always reverting in whatever version control software you're (hopefully) using, and you can always save back to older versions in LabVIEW itself.
I currently have four (older) versions installed to support projects that are under warranty. One trick I've found to be helpful is to put a .txt document in the same directory I save my .lvproj with the LabVIEW version as the title. For example, if the code is written in LabVIEW 2012 I include a text document called LV2012.txt in my _Project folder. Not a foolproof plan, but it has definitely made me double check my open version of LabVIEW before double-clicking.
I would suggest to use get VI version property described here: http://digital.ni.com/public.nsf/allkb/0C72D335AA87DD6486256FC40069C17F
Than using version information change you title bar text or transparency(I am not sure about color) or other FP component using VI ref property node.
Is there some way [software or VM] that will let me run VP in a larger box - this is really frustrating me.
I thought, from the display, that VP21 was running in DOS, so I tried "DOSBOX", but when I tried to run the VP.exe file, it came back with:
"This program must be run under Win32", so it seems to be Windows with a weird display.
The simplest is to change the setting in VP: set Options->Environment->Screen Size to "Keep original". Then exit VP, size the window the way you want it, and run VP again.
From the command line, you can do it with the mode command:
mode 120,60
is nice and large.
It is very simple (or I missed something obvious): Make a shortcut for vp.exe and edit the proporties. You can change the layout/window size to any values that your monitor allows.
I don't think you can - the app itself preventing full screen mode. And you cannot use DOSBOX because VP21 is a true Win32bit app. You can download and install "real" TurboPascal - that one will run under DOSBOX and that you can expand full screen.
We have an 'enterprisey' system with a scheduling component which gets floored if any dialogs come up. If any modal dialogs come up in the processes it is running, it gets 'paused' and can't kick off any new processes.
Excuse me a minute ...
*goes outside*
*laughs*
*cries*
*comes back*
.. ahem ... so anyway we need some sort of tool/technique that can lurk in the background and automatically detect specific dialogs and click OK on them. Any recommendations?
The offending system is running in Windows XP.
(NB: changing the third-party-enterprisey system or making its developers sit on the naughty step until they improve it are not options in the short term)
From this similar question I found:
Buzof by Basta Computing
which did the trick.
There is also a product called DialogDevil which looked promising but didn't work in our situation for some reason.
AutoIT is absolutely perfect for this. You can use the tool to help identify the dialog, write your own simple code and distribute the "auto clicker" via exe. It lurks in the background by running from the task tray.
DialogDavil will require exact same parameters on your dialog (for which you want buttons to be autoclicked) every time that same dialog pops up. And thats why it didnt work for me in first pass. Then i changed the control file at the following path to remove the changing items (a text box text in my case)
C:\Users\userName\AppData\Roaming\DAIR\DialogDevil\control.xml
And then it worked like a charm.
HTH,