I'm using wix (3.11) to create a msi installation for a WPF application. The application icon is correctly working on program launch, in the program list (apps and features), and in my program menu and desktop shortcuts. The only issue is that when I search for the application after pressing the windows key, the older, stale icon that I used a few weeks ago appears. I'm almost certain that this is some windows caching issue as I have removed the stale icon from the application altogether, rebuilt the installer and reinstalled, and still the old icon appears during search. I'm curious if other members have encountered this issue and what they did to remedy it. Thanks!
Not sure if you need to rebuild the icon cache or fix indexing issues.
For Indexing:
Type "indexing" in the start menu (or internationalized equivalent word), Click open.
Click the Advanced button.
In the Index Settings tab, click the Rebuild button under Troubleshooting. OK to confirm.
Index rebuilding should start. This Indexing applet is also available from the old-style control panel in "icons" view. Just search for "control panel" or equivalent internationalized words.
One liner code (one effective line and boiler) to refresh icons: https://github.com/crazy-max/IconsRefresh
Related
Here is the scenario:
In the Wix install script for our application , start menu shortcuts and desktop shortcuts are now handled differently than before.
These changes causes any user pinned shortcut to the application on the taskbar to be orphaned when a user runs an update from a previous installation. In other words, the shortcut remains but is no longer pointing to anything.
The shortcut is shown as a blank page indicating that the link has been removed. A quick peek at the C:\Users[UserName]\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar folder confirms this. Clicking on the shortcut will remove it and then show a windows dialog asking whether to remove the shortcut or not (answer has no meaning since it has already been removed).
My question is:
Is there any way to tell the taskbar to remove orphaned shortcuts ?
Preferrably this would be triggered by a custom action in the Wix script after installing the new version.
The roaming profile can move from machine to machine so it's pretty much impossible. About all you could do is leave behind a component that runs on logon and detects that your app is no longer installed and deletes the shortcuts.
I'd consider this user data and let the user worry about it.
some of my icons disappeared, for example the whole Microsoft office icons, they disappeared in the start menu, programm and features and also on the desktop.,
what i've tried is , to go to the folder of the exe, and pin it to the taskbar this will also show up the icon for unknown exe. changing icon doesnt work for the shortcuts, its disabled.
then i made a new shortcut and put it on the desktop that will show up the original icon. so i can recreate the start menu and the desktop, but still the icons are missed in programm and features.
i also tried to delete the icon cache db a 100 times but that doesnt work.
has anybody a solution?
does somebody know where the icon references are stored in the registry. i dont know where to start
Rebuild the icon cache.
If that doesn't work look here for a quick and easy fix.
http://www.arcane.org/the-mystery-of-the-disappearing-windows-7-start-menu-icons/
When switching between documents in VS2010 with Ctrl-Tab, the document switch window doesn't disappear until I've pressed tab multiple times to select an entry and then hit return. I'm sure that it didn't need the return previously: that the window only stayed up as long as you held down Ctrl and then when released it switched to the currently selected document. This is really annoying if you want to just hit ctrl-tab quickly to go to the last document.
I do have a few Extensions installed including Productivity Power Tools, Power Commands and VSVim, and I've also installed a couple of tools for investigating accessibility (NVDA, UIA Verifier in the platform SDK), so it's possible that one of these may have somehow changed the options.
So, my questions are:
Is the default behaviour of VS2010 that the document switch window only works while the Ctrl key is held down, or is my memory faulty?
If the default behaviour is as I remember, how do I get back to that?
I think this turned out to be an accessibility setting that was in a half-enabled state. In the Windows Accessibility settings I toggled the state of Sticky Keys a couple of times and now it's working correctly again.
This has just happened to me, and after some googling I found the solution: it was really the magnifier application I ocassionally started by pressing Win + Grey Plus. Once I have closed it the Visual Studio just worked fine without restart.
Regarding point 2.
Go to Tools : Import and Export Settings. You can then choose to reset the default environment settings again.
Also ensure than it's not an 'add-in' providing functionality different to that you expect.
Same behaviour with VS2012: when the Magnifier application is open (e.g. by pressing Windows logo key + "+" (plus sign)) this behaviour occurs even if the magnification is set to 100%.
I have a confusion that MSWord is a MDI or SDI application. Looking at the Application, I do believe that it is a SDI application but there are people who strongly "believe" that its an example of MDI. After using the Taskmanager in windows, the Applications tab list all all the instances of the Documents currently opened. However there is only one process in the Processes tab.
Since all the documents have same process, it make me feel its an MDI. But at the same time, the Applications tab lists all the documents opened make methink its an SDI. What do you people think about this? Please give your valuable and detailed answers.
If you uncheck Show all documents in the taskbar in Options, Word is a classical MDI application (even Word 2010).
If you leave it checked, it's an SDI application with multiple root windows.
According to Microsoft, it is an MDI application: http://msdn.microsoft.com/en-us/library/aa263481(v=vs.60).aspx
Depending on your settings and version, it could be MDI or SDI. It is MDI in older versions and if you use the "Show all documents in taskbar" option; otherwise, it is SDI.
Honestly, I didn't realize this part myself, until I tested:
After using the Taskmanager in windows, the Applications tab list all all the instances of the Documents currently opened. However there is only one process in the Processes tab.
Thank you and +1 on the post. On exploring further, I found something that might shed light further. I am using 2007, but I guess it would apply for 2010 as well. I clicked on the Control Menu (the small menu that pops up when you click on the Icon on the top left corner - used to be called Control Menu, before Microsoft decided to redraw its interface). You would find a "Word Options" button. Click on it, in the dialog that pops up after that, go to "Advanced" tab. Scroll down to the "Display" section. Locate the "Show all windows in the Taskbar" check box, I guess it will be checked. Uncheck it. You would see that there are no multiple windows (corresponding to each document) anymore. Also, in Task Manager, you will see only one instance even in the Applications Tab.
With this, I strongly believe Word is still an MDI. Oh by the way, if you want to see every document opened after you change these "Advanced" options, you might want to go to View menu and and chose "View side by side" option.
I came across some more info regarding this from Chris Ryan which I am sharing here:
It depends on what you mean by MDI.
MS-Word does have multiple documents and an interface but it does not fit the classic definition of an MDI application because it does not use an MDICLIENT window class to manage the child frames.
For an example of an MDICLIENT, see:
ftp://ftp.charlespetzold.com/ProgWin5/Chap19/MDIDemo/MDIDemo.c .
ftp://ftp.charlespetzold.com/ProgWin5/Chap19/MDIDemo/Release/MDIDemo.exe
Even the older versions of Word and Excel that had the child windows inside the main frame, were technically not MDI. They looked like it but they did not use MDICLIENT. MS used a proprietary windowing library called Software Dialog Manager. SDM was used so a common application code base could be used on multiple platforms: Windows, OS/2, & Mac. All they had to do was recompile for that platform and link a platform specific SDM library.
This link talks a little about SDM but does not mention MDICLIENT
http://msdn.microsoft.com/en-us/library/windows/desktop/dd317997(v=vs.85).aspx
I have a Windows form app that I've published but the end result is not what I've expected. After the wizard finishes, I click on the setup.exe and the application installs and launches, but I don't see any shortcuts in the All Programs. The application is listed in Programs and Features but when I close the app, there is no icon to click to launch it again. I've searched for an executable file in the Program Files and System32 folders found nothing.
So what I wanted to to do is create a desktop shrtcut, or shortcut in the All Programs as part of the installation process.
Also how do I assign a custom icon that will show up in the task bar?
Thanks,
Risho
create-setup-and-deployment-of-wpf-application-step-by-step
Is very helpful link for new users. Wpf and windows Forms are not much different in Deployment.
Assuming you are talking about ClickOnce publishing, you can ensure that desktop shortcuts and start menu shortcuts are created by selecting the 'The application is available offline as well (launchable from start menu)' radio button in the publish tab of the project properties, and clicking the 'Create desktop shortcut' checkbox in the Publish Options window.
I figured it out. For some reason, Visual Studio used the registered name under which it was installed, which is my employer, to create a shortcut on the All Programs and dropped the program shortcut there.
I also found in the project property page where to set the desktop icon.
Man, I'm good - sheesh! (JK)
Have great day.