I have made a toolbar that I want to enable from a systray application written in C#, the actual toolbar enabling is done from a C++ part using [DLLImport].
Current I use:
SHLoadInProc(__uuidof(MyBandLoader))
but this fails on vista (SHLoadInProc is not implemented any more), and on Windows XP SP2 with IE6 (the quick launch toolbar vanishes after reboot).
On Vista I have tried to with: CocreateInstance() and BandSite->AddBand(), but using the guid of the toolbar dll gave me either a segmentation fault or the address bar.
Is there another way to enable a toolbar from another program on XP and Vista?
On Vista there's a new poorly-documented interface called ITrayDeskBand.
Create an instance of this via CoCreateInstance, and then call ShowDeskBand([CLSID of your toolbar]) on the returned pointer (in C++ - I'm not sure how you create all the relevant bits for PInvoke in C# - might be easier to write a simple C++ dll to expose this function)
That only works on Vista though, on XP you need to continue with the SHLoadInProc method above, so you need to test the OS version and do the appropriate thing.
Be careful if you're lifting code from that codeproject article - it's full of subtle bugs, although many of them are discussed in the comments
I have used that one, but it only tells you have to make a toolbar, not how to enable it from another program.
One should never use .Net to create any COM objects inside the Explorer process. This will just not work if there is another .net component using a different framework version already loaded into the explorers process. Only one .net framework for each process. MS should have never propaged samples about developing deskbands in any .net language.
The only way on Vista an up is to use the ITrayDeskBand interface to display the toolbar. However, this will display a confirmation box to the user and he can refuse the toolbar to be shown.
Related
so I'm implementing printing for my UWP app following this guide https://learn.microsoft.com/en-us/windows/uwp/winrt-components/brokered-windows-runtime-components-for-side-loaded-windows-store-apps#creating-and-deploying-the-windows-runtime-proxy
I have a bug where the printer stops working and I realized one fix is to go into task manager and delete the COM Surrogate associated with a dll. I'm not sure how to find out what dll this is, has anyone ran into this issue before?
I would think the fix is to relink the component somehow but am not sure how.
The proper way to print from a UWP is using the Windows.Graphics.Printing, Windows.UI.Xaml.Printing, PrintDocument APIs as documented here:
https://learn.microsoft.com/en-us/windows/uwp/devices-sensors/print-from-your-app
One thing to note is that this approach currently does not support silent/unattended print scenarios. For those you would have to work around using classic Win32 printing API, either from a brokered component (as you tried) or using a desktop extension to your UWP. The latter is the preferred route (brokered components is Win8 era tech). I have a quick tutorial on desktop extensions here: https://stefanwick.com/2018/04/06/uwp-with-desktop-extension-part-1/ and a very simple silent printing sample here: 1drv.ms/u/s!AovTwKUMywTNnOsbzlRfghOikDy8Dw
I have used this technique (Brokered Windows Runtime Components) in an LOB app for several years, and it is always a PITA for the maintenance.
Every time I have made an update to Brokered Windows Runtime Component I will need to register it again using regsvr32.exe. If I have run the app and COM Surrogate is already running, the registration will fail. I will need to reboot the system, or I have to kill the running "dllhost.exe" in task manager - there might be several instances of dllhost.exe, and I just kill the ones that run under the current logon user, and leave those run as SYSTEM.
One of the dllhost.exe instances hosts the DLL you created and registered. It is not clear why printer stops working so I can't give an answer. To help investigation, add some logs to these points.
When the app code is calling the Brokered Windows Runtime Component, check the return value of the call, and try and catch any exception.
Inside the Brokered Windows Runtime Component, at the entry and exit of the method that is being called by the App.
Check the code that uses printer, is it working correctly? or is it being called at all?
I created a DLL in Visual Studiio 2013 which works with the manipulation-event and outputs refined translation, rotation and scaling. Afterwards I tried to merge this with a OpenGL-Project, to provide proper gesture support.
The DLL is build with .NET 4.0 Client Profile selected, and I tested it with a simple implementation in VS2013. Everything worked flawless and the setup was pretty easy.
Now the OpenGL Project is being maintained and developed in VS2010, so I fired up VS2010, referenced my DLL and did an override on the WndProc to get the WM_POINTER* events into my DLL.
The problem is that I do not get the events ! I not once managed to receive a WM_POINTER* event.
I have some ideas:
Development machine is Win 7, test machine is Win 8 - maybe some WIN8 Features are required at build time ?
I simply can't work with Win8 API in VS2010, even if I only use a DLL generated in VS2013
Windows somehow determines that I do not want WM_POINTER* events as I run a Application not explicitly developed for Windows 8 (Not sure how I could change that)
I've already tested various versions of the .NET Framework, so it's not a .NET issue.
I furthermore verified that no WM_POINTER* events are fired for this particular application (in any other it works just fine) and that my WndProc override is working properly.
I am pretty desperate and have no real clue what else to try.
Would be really glad if anyone with WIN8 Pointer experience could help me out.
Cheers !
Edit: Forgot to mention that the OpenGL-Project is basically a WinForms Application.
WM_POINTER messages were introduced in Windows 8, and that's why it doesn't work in your development machine. You will need to resort to the old, deprecated WM_TOUCH and WM_GESTURE messages: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/b8cb28dd-b2ba-4392-b3a8-6bf18518087f/windows-8-wmpointer-vs-wmtouch?forum=tabletandtouch
For anyone stumbling about this:
Reddit-User darinitis wrote this
Did you have an OpenGL window in VS2013, or was the test just to
capture gestures in a winforms project?
OpenGL may be creating a window in front of, or as a child of your
winforms window. Because the pointer is never actually over your
window (it is on the GL one), you don't get the pointer messages.
Have you used Spy++ to see the actual window hierarchy and see if
another window is being created for OpenGL above your window?
And was right on spot. The OpenGL child I had did not forward the events but tried to handle them. This way nothing ever arrived in my WinForms application.
I've searched a lot these days to find a way to programmatically hide or disable the start button in Windows 8.1, but could not find any useful information
Is there any way to do this? Either with C# or with some registry-keys...
A short explanation why I need to hide the button:
We have a .NET Desktop Application which runs on WinXP, Vista and 7 in a self-made kiosk mode. Now we have to get it running in Win8 (8.1) but as expected, the new Start-Menu (Metro, Modern UI, whatever you call it) is always there.
I already managed to disable the Hot Corners, but the Start Button in the left corner still appears when you move you mouse over it, and it also starts the Metro - what we don't want.
Any help would be appreciated!
It seems that there is no such way...
But you could use a third party tool like one of these http://lifehacker.com/how-can-i-hide-the-start-button-in-windows-8-1-1478012124.
This question belongs on SuperUser, since it's not code related, but I'll have a go at it.. You should create a system account with an assigned access. Here, read these two articles: first second
According to these articles, it shouldn't take you more than 5 minutes to achieve what you want.
... find a way to programmatically hide or disable the start button in Windows 8.1...
See Registry Key Controlling Start Button in Windows 8.1? on SuperUser. According to one commentor, there is no simple fix like a registry key. Tools like 7+ Taskbar Tweaker inject a DLL into explorer hook/subclass/redirect some of its methods.
If you are going to write your own DLL and inject it into Explorer, then you might want to take a look at Microsoft's Detours Library. I've used it in the past and its actually easy to use. The description from the website: Detours intercepts Win32 functions by re-writing the in-memory code for target functions. The Detours package also contains utilities to attach arbitrary DLLs and data segments to any Win32 binary.
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 trying to automate a hidden .NET application, with another .NET application (written in c#) using the easiest way possible. It's NOT for testing purposes, it's a way to fulfill the lack of scripting for this application.
I already tried white framework, but there is one major problems with it: the way it's working. It's slow and it's not working on hidden windows and controls (like the winAPI does). Whats more, when "clicking" white moves the mouse, brings it's targeted window to the front and so on.
I was also thinking about using a user32.dll wrapper, because the way it's handling it's target is what I need, but I've red it's not working with .NET applications. It also would be a problem working with it, because my targeted application got 5 button labeled "...", and would be really hard finding 2 of them I need. I also would like to use the controls .NET id (the name the developer gave to it's controls when designing the GUI).
BTW, my targeted application is MeGUI if that helps. We do a lot of video encoding and a tool like this would help us a lot. I need the MeGUI to be hidden, because I'm the only programmer, others using my tool shouldn't see what happens in the background, not to talk about the many windows popping all around.
You can add a reference to the exe from your project and then create an AppDomain to run its main method. From there, it should be possible to queue delegates to its main thread's loop. With a bit of reflection, you could have those delegates invoke the click events and whatnot directly.
I've never attempted this approach, but it should work.
You should try Stephens idea instead of scripting a hidden app. A .NET Windows Forms App (EXE) is still a .NET Assembly and that means you can use that the same way as a DLL, just add a reference and use the public classes.
If you still want to try some scripting, take a look on the "Microsoft UI Automation" API and the "System.Windows.Automation" namespace.
Nice article here: http://msdn.microsoft.com/en-us/magazine/cc163465.aspx
MSDN Doc: http://msdn.microsoft.com/en-us/library/system.windows.automation.aspx