I need to reproduce partly a behavior of StarTeam 2005 client's dialog box "Folder Properties" in my tool based on StarTeam 2005 SDK. Unfortunately, when I has tried to implement "working folder's changing" feature I has confronted with some trouble.
I has found read/write IStFolder object's properties DefaultPathFragment and AlternatePathFragment, but cann't to find any method/property what allows to switch between deafult/alternate paths' usage.
Also, named properties' changes always stores locally only, never stores on server, even after update() method usage (as opposite to, e.g., Name property's changes)
Can I to implement named functionality somehow?
While working with the SDK, the "Alternate Path to Folder" is not kept in any way,
and once the session is closed (i.e.: your tool stops running) - that information is forgotten -
in other words: the Alternate Path to Folder is not persistent.
Note also that whatever "Alternate Path to Folder" you have set in your StarTeam Client,
this information will not be available to the StarTeam SDK session,
even if you run it on the same PC as the same user.
Related
I'm trying to run a ClickOnce installer and I get this useless error message from Windows 7: "Windows can't open this file".
The file extension is .appref-ms
Has anyone seen this or have any advice?
I had this issue on a client's machine. It appears that the operating system does not know the correct association for the file extension, but in reality .appref-ms is not a normal extension and is not directly associated with any program.
I found the following page eventually:
https://social.msdn.microsoft.com/forums/windows/en-us/9ff7867c-7e57-468c-a632-762a76f66f6d/windows-7-64-bit-unable-to-open-apprefms
This contains some information on restoring potentially damaged registry keys, which can cause this issue. However, in my opinion it gives the wrong advice to associate dfshim.dll with .appref-ms. When I did this, it created an association to that dll in the registry, but upon checking the registry of a working machine, no such association exists. This association also causes .appref-ms files to lose their application specific icons, and display instead this icon:
In addition, this association did not actually launch my application successfully, but for some others it may actually work (I don't know).
The correct solution is to restore even more registry keys, which cascade to allow windows to treat .appref-ms files more like applications than files to be opened with programs. The necessary keys are below (I may have overzealously included a couple that are not strictly necessary, but at least some of them are):
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.appref-ms]
#="Application.Reference"
[HKEY_CLASSES_ROOT\.application]
"Content Type"="application/x-ms-application"
#="Application.Manifest"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Reference\shell]
#="open"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Reference\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Reference\shell\open\command]
#="\"C:\\Windows\\System32\\rundll32.exe\" \"C:\\Windows\\System32\\dfshim.dll\",ShOpenVerbShortcut %1|%2"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Manifest\shell]
#="open"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Manifest\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Manifest\shell\open\command]
#="\"C:\\Windows\\System32\\rundll32.exe\" \"C:\\Windows\\System32\\dfshim.dll\",ShOpenVerbApplication %1"
This appears to apply to both .application and .appref-ms type files. The first key identifies .appref-ms as class "Application.Reference". The later key under "Classes\Application.Reference" defines how these types are launched. These are not simple "open with" associations that Windows is trying to help you create (and which will be created under HKCU instead of HKLM).
Windows explorer uses DDE to communicate with applications for things like file-opening. These DDE-commands can be set in the "folder options" of Windows explorer. Matlab has an undocumented DDE-interface, which I use for telling Matlab to analyze any file I double-click in Explorer.
I recently upgraded from Matlab2011a to Matlab2013a. In folder options, I updated the path in the "Application Used to Perform this Action" field to point to the new Matlab binary. For all my previous upgrades this was enough to make it work. But now, instead of analyzing the file in the instance of Matlab that is already running, a new Matlab instance is opened for every file!
What is causing this error?
Because Matlab's DDE-interface is undocumented, Mathworks feels free (and has every right) to change the DDE-behaviour between versions. In Matlab2013a they changed the DDE "Application Name" so that it now includes the version of Matlab. In this case, the correct "Application Name" is ShellVerbs.Matlab.8.1.0.
For reference, here is a screenshot of the settings (sorry, my Windows XP is in German.)
In Vista, I have been using an IFileSaveDialog to let users pick a "save-as" folder. Users export a folder of images, say, and need to choose a new or existing target folder.
Briefly, the code goes like this:
IFileSaveDialog* dialog; // created
dialog->SetOptions(FOS_PICKFOLDERS);
dialog->Show(NULL);
dialog->GetResult(&shellItem)
In Windows 7, the FOS_PICKFOLDERS option appears to have been disallowed (and is marked as such in the API). The return value on the SetOptions call is E_INVALIDARG. If I use a IFileOpenDialog, I'm allowed to set the folders option, but the user is prompted with an error when choosing a nonexistent folder (despite my setting flags suggesting not to do this).
Is there an alternate way to get the new IFileDialog to act as a "save folder" dialog?
[To head off some comments, the SHBrowseForFolder API still exists, but is still not an acceptable solution for our UI deciders.]
The reason for this can be found in the documentation:
FOS_PICKFOLDERS: Present the Open dialog offering a choice of folders rather than files.
Using FOS_PICKFOLDERS for "save" was never supposed to be supported - but Vista didn't enforce it. Use IFileOpenDialog instead and you're good to go.
You are picking an existing folder (not specifying a folder to create), so open was always the correct choice.
I haven't played around with the Windows 7 dialogs yet, but downloaded the Windows® API Code Pack just this morning as I am implementing the Thumbnail Toolbar and Icon Overlay in the application I am working on. It'll probably point you in the right direction.
Recently I had to troubleshoot a very strange issue with a fully-trusted InfoPath 2007 form at a customer site. The form is part of a records management application and users launch the form from within the application.
However, because the form is subject to frequent updates, we store a "master" copy of the form file on the customer's server. Whenever a user launches the form from our application, our software copies the form .xsn file locally to the Application Data folder, registers the local copy, and then launches it. Note that we don't use certificates, which is why we need to programmatically register the form each time it is launched.
This customer was having trouble launching the form from our application on one of their workstations. The logs indicated that the form couldn't be registered on this particular workstation (the form gets registered and opens fine on other workstations, all of which are running Windows XP).
Our software uses the InfoPath.ExternalApplication class to register and launch the .xsn file. The following VBScript reproduced the issue on the problem workstation:
Set infoPathApp = CreateObject("InfoPath.ExternalApplication")
'This line produces a pretty generic "Form template could not be registered" error,'
'with absolutely no details as to *why* it could not be registered.'
infoPathApp.RegisterSolution "C:\Documents And Settings\All Users\Application Data\MyCompanysApp\MyCompanysInfoPathForm.xsn", "overwrite"
The really strange thing that I cannot for the life of me understand is that if I change
"C:\Documents And Settings\All Users\Application Data\MyCompanysApp\MyCompanysInfoPathForm.xsn"
to this:
"C:\Documents And Settings\All USers\Application Data\MyCompanysApp\MyCompanysInfoPathForm.xsn"
Then the form registers fine and the user can then open the form without any issues! Note that the only difference between the working and non-working code is that I changed "All Users" to "All USers" (capitialized the first "S" in "Users").
What the heck is going on here? Why would the casing of the filepath matter at all to InfoPath? What's more, why would the odd-cased version (with "All USers") work while the (obviously more correct "All Users") doesn't?
Also, for what it's worth, the "All Users" folder does appear as "All Users" and not "All USers" in Windows Explorer and in the file properties.
Update
I can only assume that something is different between the two workstations, but I'm at a loss as to what to look for in terms of differences. I realize I haven't provided a lot of details in the question (because I really have no idea what could be causing this behavior), but if anyone has any clues or possible causes, I'd be happy to hear them.
This is a shot in the dark but:
Have you tried clearing the internet explorer cache and rebooting the workstation?
(In IE go to Tools->Internet Options, click Delete..., click Delete all...)
Also clear your InfoPath form cache while you are at it.
InfoPath saves form data in this cache and does not seem to clear it properly. This causes quite a few problems for me where an old file is opened from the cache when it shouldn't be. The change in the path may be causing a cache miss allowing your code to run properly.
If that doesn't work, the next question I would have would be:
Do you have this issue for all users on this workstation, or have you tried it with only one user?
Last few days i have been working on building an application to hide folders(thanks to the paid versions of such softwares). After a heavy googling I zeroed into some shell script that would first create a folder and then rename the folder to "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}". It would then hide this folder by using the command attrib -s -h Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}. The funda behind this is to make it a system folder and hide it. But if you would uncheck the Hide sytem folders in Folder option the control panel becomes visible. I would like to make this folder completely invisible as how the other folder protecting softwares do.
Can somebody throw some more light on this?
Thanks a ton...
Most folder hiding software works by implementing either an extension for Windows Explorer or a file system filter driver.
The first method means that certain items will not be visible when browsing folders in Windows via the UI, but will still be visible to other software and via the command prompt. For example, the Recycle Bin and Temporary Internet Files folders work this way.
The file system filter driver method proxies calls between Windows and the underlying file system and only allows certain requests through. This is similar to how virus scanners prevent access to infected files.
The general idea is that you hook the file system API's and filter out the file system entries you want to hide.
But JelloMonkey is right - this is rootkit behavior and you will get flagged as malicious by rootkit detectors for this kind of behavior. That's likely to get your entire directory quarantined or deleted.