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?
Related
I am using Windows 10 and whenever I try to copy paste some content in any folder, my system refreshes (reloaded) and file explorer window closed without executing the copy-pasting task. On right click on any folder, also refreshes the system and nothing happens.
To my knowledge, some Microsoft service is causing this issue, don't know which service. Any leads, please?
I tried to run the system on safe mode with basic services and it works fine. On the other hand, when I disable all the 3rd party services and restart the system with only Microsoft's services, the same issue again. that means there is some Microsft services which are causing the issue.
try to run Windows on safe mode, and enable one by one each service, spaced by tests, and if your poblem occur after enabling a service, I think you would find out wich service is causing your problem
And then, Google "(service name) problem copy paste Windows 10" and see if others have this problem
hope it help
I am trying to open a locked excel sheet. The warning says it is locked because it is being used by "AN Other".
This person does not have the sheet open, does not have any excel applications open, does not have any excel based tasks running in the task list and has tried the good old "turning it off and on again".
Neither of us can save onto this filename, change it in windows explorer or delete the file.
We have "saved as" another name but really need the original name. I looked at a few forums and they suggest this is an excel/windows bug.
Am using excel 2010 and Windows 7.
You need to get in touch with your IT support.
In a company network, a file will be locked for other users when somebody edits it. It can happen sometimes that the file does not get released (unlocked) when the user closes it. Your IT Support people need to unlock the file, so you can edit it again.
I use Inno Setup as my installer. The installer failed to register a DLL. It turned out that regsvr32 failed with error code 0x80070005, which stands for E_ACCESSDENIED. When I opened "C:\Program Files\MyProgram\" in Explorer it showed some sort of a UAC dialog asking for elevated priviledges to view it. I noticed that all the files have a padlock on their icons. This is the first time I've seen this padlock.
I checked in Process Explorer and the installer was started from the regular user account (with elevated priviledges).
Update
I want to add that this error has so far only happened once. When I closed the installer and started it again (the same exact executable, I haven't made any changes to it), everything went fine and the files in the program's directory had normal permissions. This is not a consistently reproducible bug, more like a one in a million times bug, but if it's happened once on my machine, it likely has happened on users' mahcines too.
As it's reporting you don't have access to that folder (and in turn those files). Check the permissions as this is NOT the default state and must have been explicitly changed.
I have a program that was written on XP. What I've found out is that it doesn't work properly on Win7 because HLKM is no longer writable by non-admins.
Essentially, when you register the program, the licensing information is supposed to go into the registry. That information is valid for everyone on the computer, not just the one user, so I don't want to put it in HKCU. But any copy of the program needs to be able to edit that registry (even if it's a non-admin running it), because there are certain situations when it's going to go get updated license information from my web server (for example, if the registry data is lost or damaged, or if your current license is expired and it needs to see if we've applied an extension).
It's not horrible if it goes out to the web server for every unique user who starts up the program, but it causes some annoying issues, so I'd rather it continue to work the way it did in XP. Is there a way to store data in the registry and still have it shared under Win7, or am I going to have to start looking at storing an INI file on the drive?
Here is how I would architect it: your setup runs elevated and sets up the key. Then if their licensing gets corrupted or whatnot, you enable a button or menu item that has text like "fix license" or "update license". You put a shield on that button or menu item. When they click it, you launch a separate exe using ShellExecute. That exe has a manifest that requires elevation. It can then write to the protected area of the registry. The rest of the app can have a manifest with asInvoker.
If you want it to be completely invisible, either the whole app must always run elevated (annoying) or sometimes the app will just launch another exe that asks for elevation without warning - in which case the smart users will say no. A little less invisibility is a good thing imo.
Could you get the installer to make your particular area of the registry to be writeable by everyone? The installer will need to be run with elevated privileges anyway, I'd expect - so this would seem an ideal approach.
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.