Sorry for my very bad english.
How to reassign the folder "windows\system32" for only my application to GetSystemDirectory return my path. I tried to play with SHSetFolderPath
SHSetFolderPathA (CSIDL_SYSTEM, NULL, 0, "c:\\WINDOWS\\system33");
but I get error 0x80070057 (bad args).
How do this? Is it possible?
It fails because it is something that cannot be done.
The documentation states that this error code is returned if:
The csidl value is not valid.
The csidl value does not refer to a virtual folder.
The csidl value does not refer to a system folder.
The csidl value refers to a folder that cannot be renamed or moved.
The dwFlags value is not 0 (zero).
The pszPath value is NULL.
The string pointed to by pszPath value is an empty string ("") of
length zero.
I have highlighted the item that is pertinent to your question.
This function exists to allow you to renamed things like the "My Documents" folder. It doesn't make sense to rename the system directory.
Clearly you have a problem that needs to be solved but this is not the problem. Perhaps if you expanded on the problem we could help with it.
Related
I am struggling to find out how the “SHParseDisplayName” function builds the output absolute pidl.
I absolutely need to control its output.
To understand what I mean I make two examples:
Executing SHParseDisplayName("C:\\Users\\Username\\Onedrive", IntPtr.Zero, out pidl, 0, out psfgaoOut) the absolute "pidl" output variable is composed by these pidls (obtained by executing in sequence SHGetNameFromIDList(pidl, SIGDN.PARENTRELATIVEPARSING, out name) and ILRemoveLastID(pidl) until I reach the root):
::{018D5C66-4533-4307-9B53-224DE2ED1FE6}
Desktop
Executing the same for "C:\Users\Username\Pictures" the result is:
::{24AD3AD4-A569-4530-98E1-AB02F9417AA8}
::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
Desktop
At first, I thought that the absolute pidl was composed based on the “pszParsingName” value of the KNOWNFOLDER_DEFINITION of the relative known folder so I created a new known folder using IKnownFolderManager::RegisterFolder and setting a particular Shell namespace folder path in the “pszParsingName” value of the KNOWNFOLDER_DEFINITION.
Unfortunately the absolute pidl output was not the one expected. (And I added the new known folder path also in “user shell folders” registry key)
So I am asking your help to find out how I can control the building of the absolute pidl output of the “SHParseDisplayName” function.
Thanks a lot for any help
I need to remember the original setting of the iTunes Media Folder Location setting so I can restore its value after changing it (possibly) more than once.
What is the easiest way to accomplish this?
com.apple.iApps.plist is the correct place to look.
The key "iTunesRecentDatabasePaths" is a String Array, item 0 holds the most recent entry in a form relative to the User's Home directory. Meaning it will probably start with a ~ character.
The key "iTunesRecentDatabases" is a String Array, item 0 holds the most recent entry in the form of a fully qualified "File://" URL.
I have an alert box, and if I'm currently on the test Database, I want the alert box to have different text when compared to live database.
So I declared a variable called isTestDb and set it to True, but I keep getting this annoying error:
Microsoft VBScript compilation error '800a0411'
Name redefined
myfiles/conn_open.asp, line 12
Dim isTestDb
----^
Here is my simple code which sits inside an include at a much higher level than where I'm doing my conditional check, I'm assuming that isn't a problem.
Dim isTestDb
isTestDb = True
-- Much Later in another file somehwere
If isTestDb Then
Response.Write("<h1>It is set to True</h1>")
Response.End
Else
Response.Write("<h1>It is set to False</h1>")
Response.End
End If
I have checked all my working directory and I'm certain that variable is not set somewhere else by the same name, I even tried different names for the variable and got the exact same error.
In my case this was due to the fact that I had referenced the same file twice in my .asp file using:
<!--#include file="myFile.asp">
And the referenced file had the declaration in it hence the second declaration conflicted with the first
This is happenning because the variable, isTestDb has already been defined in another page.
I have no idea why, but when I removed the Dim isTestDb line, it all works as expected now!! :/
it can also be because you are including file you already including in other include file.
For example:
File a.asp is including x.asp.
And in your main file you including both:
<!--#include file="a.asp">
<!--#include file="x.asp">
I am trying to animate an actor in Clutter, but when I enter a property that exists, something goes wrong.
actor.animate( AnimationMode.LINEAR, 400, scale_x:2);
gives me this error
Clutter-WARNING **: Cannot bind property '\x83\xec\u0014\x89\xc6e\xa1\u000c': objects of type 'ClutterTexture' do not have this property
Looks like Unicode-characters to me.
However, when I enter a property that does NOT exist
actor.animate( AnimationMode.LINEAR, 400, thisdoesntwork:2);
I get an error that makes much more sense
Clutter-WARNING **: Cannot bind property 'thisdoesntwork': objects of type 'ClutterTexture' do not have this property
I get the exact same problem when I try this alternative approach:
actor.animate( AnimationMode.LINEAR, 400, "scale-x", 2);
How come all properties that actually exist get converted to some mess, and what can I do to get this to work?
You should be using 2.0 for the value, not 2. 2 is an integer, 2.0 is a double. Vala can't provide type safety for variadic methods, so you have to be careful.
As for why you're seeing the behavior you are for properties which exist, my guess is it has to do with the fact that 2 is a (32-bit) integer and 2.0 is a (64-bit) double. This is simplifying things a bit, and I don't know how much experience you have with C (probably not a lot, since this is the sort of mistake someone coming from a dynamically typed language would make), however... Clutter (well, va_arg) expects a double so it parses 64 bits of data, but you only provided 32 bits, so the first 32-bits of the next argument (NULL) are included. Now, when it starts trying to parse the next argument it starts from the wrong location (32-bits into the argument), so you get the the remainder of NULL and part of whatever garbage happened to be on the stack... Unsuprisingly, that doesn't just so happen to be 32-bits of 0s so when Clutter tests to see if the value it just read == NULL it isn't and Clutter thinks it's been given a pointer to an null-terminated array of characters (which is how strings are represented in C). It reads the data at that location, which just so happens to be \x83\xec\u0014\x89\xc6e\xa1\u000c, and checks to see if there is a property with that name. There isn't, so it emits the error message you saw.
Now, if you switch to using a property which doesn't exist, Clutter will parse the argument (the name of the property), notice that it doesn't exist (just like it did with the second property above), and emit an error.
Is there a way to get the SearchPath API to not search in c:\windows when using the default search path (passing NULL as the first param)? I can't modify the caller to send in a specific path.
I have a system with an application ini file in c:\windows (which I don't want it to use, but for legacy reasons has to remain there). I put my copy of the same ini file in c:\users\public, and put c:\users\public at the front of my system path environment variable, but a call to SearchPath still finds the c:\windows version. If I delete that version, it then finds the c:\users\public version, so I know the path was set correctly.
I know this is very late, but having just run into this problem myself, I would propose a better solution.
The first argument to SearchPath, as you have found, can be used to specify the directories you want it to search, instead of the default order. You can retrieve and use the current user's PATH with GetEnvironmentVariable, and then search within that:
DWORD err = GetEnvironmentVariable("PATH", NULL, 0);
char* path = new char[err+1]; path[err] = 0;
GetEnvironmentVariable("PATH", path, err);
err = SearchPath(path, "application", ".ini", 0, NULL, NULL);
char* searchResult = new char[err+1]; searchResult[err] = 0;
err = SearchPath(path, "application", ".ini", err, searchResult, NULL);
According to MSDN, there's nothing you can do about this bar changing a system level (HKLM) registry entry (Which is a "bad thing"). The registry change would cause the search order to start with the current working directory, which you could set to the desired folder in a shortcut. (Again, I'm going to say; changing a Machine Level registry entry to do this - is potentially dangerous!)
Have you looked into application shims? This may be something that could work for you.
Try SetCurrentDirectory("c:\users\public") and then SearchPath(...).