I am launching openoffice 3.3.0 on Windows 7 from a WPF app no problem, however when launching on XP openoffice always goes behind my WPF any way to stop this ?
C:\Program Files\OpenOffice.org 3\program\soffice.exe
Guessing here.
Is there no way to launch a program and specify that it opens on-top/in-front?
Or do you need to minimize the WPF application to allow OO.o to show up on top. You may just have gotten lucky on Windows 7.
Related
I'm trying to solve a problem related to run an UWP app on top at startup (with Winodws 10).
I already put the app in the autorun applications but it always runs in background (the application is opened and if I click on the icon in the application bar I can see it). Unfortunately, I would like that it runs automatically on top.
How can I solve it?
#Xavier Xie We are also facing the same problem, what we are trying to build is a Windows 10 IoT machine that displays latest contents in fullscreen from a server automatically whenever the machine is started up / restart. Tried with StartupTask but it only brings up the App minimized / suspended at Windows startup.
The only way workaround for now is to drag a shortcut link of the installed UWP App into the startup folder. (type "shell:startup" in Explorer) Not as elegant and automatic but it works.
Is there a way to do this?
Or at least download the executable and letting user open it?
I want to create a WinRT that depends on a desktop service like this
So either sideload the WinRT from desktop or install the desktop app from Metro.
You can't do that in WinRT today. If you had an executable created for ARM Windows RT today, then you could run the app but Microsoft has not released any tools to create such an executable that runs as a desktop app on Windows RT.
I have an application in which i am using notifyicon.The application is meant to run at windows startup.The application is getting started in both the OS as i can see the process in task manager but in windows server 2003 the notify icon is not visible.I am clueless why this kind of behavior.The notifyIcon is visible in windows Xp.
I came across this NotifyIcon not showing
but this is not the problem.
Solved the Problem by bumping up the delay at the startup with the help of a script.
Problem seems to be with windows shell.dll
I'm programming in C# under win7 and windows XP. My software needs to auto start when the system starts. So I modified the registry to conform to this requirement, but when I start the computer, the desktop will show for a while. I know this is because explorer.exe runs before the auto-start program. I want to how to let my program run before explorer so that the desktop could not be shown? Does anyone have any insight?
Did you try making it a Windows Service (Visual Studio project type)?
And the setting the service to autostart.
What you are looking for are Windows Services. Do be advised though, that explorer.exe sort of is Windows. So I doubt you will achieve whatever it is you are trying to achieve.
I have created a deskband for Windows XP after following the tutorial in codeproject. It works perfect. However, some of the users use Windows 7 and they found they cannot use the deskband I created.
Could anyone let me know how to fix the problem?
Update: After the Windows 7 users installed the deskband (msi file), they cannot see it in the windows toolbars (right click mouse on taskbar > toolbars > ). The deskband is visible in the toolbar in the IE in Windows 7 though (The BandObject creates deskband for windows toolbar and for IE toolbar) .
Thanks!
Since Shell extensions are COM objects you should be able to find the GUID used to identify the object in the registry on machines where it works or in your project/build files. Make sure it is getting registered correctly on the Windows 7 machines by searching the registry or using something like the OLE-COM Object Viewer.
Run you MSI file with verbose logging to find out if there are installation problems. The deskband needs to be registered correctly and this could fail silently depending on how it is being registered.
As I said in my comment above, writing extensions in managed (.NET) code has historically been a problem. Some people can get away with it though.