My application uses SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, szPath) to get the file path for application data. A user reported (via a Survey Monkey survey) a bug as reported below --
"Win XP uses partly a Czech name "C:\Documents and Settings\%my profile%\Data aplikací" The letter í (i with acute) causes a problem: The library.db file cannot be found since the program searches "Data aplikac" instead of the correct "Data aplikací" as I have seen in the File Monitor."
How do I rectify this problem? It is difficult for me to debug the problem without a Czech user I can communicate with.
The application is compiled for MBCS not Unicode.
Related
I have spent time googling but without results. I get following error when creating projects with latest android studio:
Invalid file name: 'con'
New Module was only partially completed.
Your project may not compile.
You may want to Undo to get back to the original state
I have also tried previous version of android studio, but without any result.
What could be the cause of this issue and how can I correct it? I am on Windows 10.
Thank you
I Feel silly now because it was because of con word in package name. The accepted answer helped.
A module name is automatically used as directory name.
As you are on Windows the file-system has several file- and folder-names that are disallowed. con is one such disallowed names (case insensitive).
This means no matter what file-system you use as long as you are running Android Studio on Windows you will never ab able to create a file or a folder named con.
Other disallowed file names are:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. source
Therefore you have two possibilities: Use a different name for the module or use a different OS.
I have created a VBA add-in for Microsoft Word. Both a Windows and Mac version. The add-in communicates with 3rd party apps.
This has worked fine for years. I'm now struggling making this work for the Mac-version with M1-based macs (Maybe also Big Sur related).
The communication works partly via a dylib written i c, via stdin and stdout.
Secondly some functions use AppleScriptTask.
I can't make either of these two methods work.
AppleScriptTask always return the error:
Run-time error '5'
Invalid procedure call or argument
VBA-code:
s = AppleScriptTask("WMscript.scpt","Test","")
I tried scripts with .scpt, .scptd and .applescript.
Also newly created scriptfiles with simple test.script:
on Test(paramS)
tell application "Finder"
activate
end tell
end Test
The api works in other applications, but I can't open 3rd party apps in it when used from VBA.
I use these special folders for the all the 3rd party files to circumvent sandboxing for both methods:
/Library/Application support/Microsoft/Office365/User Content/Add-ins/
~/Library/Application Scripts/com.microsoft.word/
~/Library/containers/com.microsoft.word/Data/
I also tried the GrantAccessToMultipleFiles(FileArray) function. It always returns 'True' regardless which filenames are sendt in the array. It never prompt the user.
Running:
M1 Mac
Big sur 11.6 (M1)
Microsoft Word for Mac 16.54 (21101001)
Not sure following will help you.
If your third-party application is from unknown developer, then it goes to GateKeeper quarantine. Try to remove quarantine before calling your VBA script, running following script.
set theApp to application id "Avidemux.org" -- EDIT here the bundle ID
set quotedPath to quoted form of (POSIX path of (path to theApp))
do shell script "xattr -rd com.apple.quarantine " & ¬
quotedPath with administrator privileges
You can include the code above to beginning of your VBA script.
The ApplceScriptTask problem was related to an incorrect path, for the script file:
Incorrect: ~/Library/Application Scripts/com.microsoft.word/
Correct: ~/Library/Application Scripts/com.microsoft.Word/
Had to be Uppercase W.
I switched my CI tool to call dotnet build on Linux whereas I was previoulsy doing it on Windows. Then I suddenly had a bug in my app.
I am comparing a variable read from database to a string litteral (directly in the code) returned from a method. The string litteral has French accents. So does the value stored in the db (SQL Server).
However, the line that does the string comparison returns true when built on Windows but false when built from Linux.
How come?
UPDATE
Here the exception message that showed me the issue:
throw new ArgumentOutOfRangeException(nameof(modeDePaiement), modeDePaiement, "Mode de paiement non supporté");
When displaying the error, modeDePaiement was equal to "prélèvement" both when built from Windows or Linux.
However, the value it is compared against AS WELL AS the word "supporté" in the error message weren't displayed equally: when built from Linux the "é" is replaced with some symbol whereas it is correctly displayed when built from Windows.
It seems that strings, in code, are not encoded the same way when built from Linux or Windows.
I am going to use Stimulsoft Reports.Wpf (Version: 2010.1.700 from 26 March 2010) to prepare some reports but unfortunately Sometimes when i want to create a new data source,an error is appeared saying :
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
An unhandled exception of type 'System.Reflection.ReflectionTypeLoadException' occurred in mscorlib.dll
last time that i saw this thing , i didn't do anything special about it.surprisingly it was fixed by itself.But this time it seems it is not going to work.
i have searched the internet 1000 of times but i didn't find anything useful.
what should i do to fix it ?
I Have this problem too. i install some font that was used in report. this problem solved.
or may be because of application cant find stimul soft reports needed dll files.
if reports call from another class library project.
if main exe file and class library report caller has different physical path in windows you have to copy stimulsoft report files into main exe file path and also into report caller dll path too.
I had a customer reporting problems with a file in a specific path. Debugging some old Windows code, I have found that the code in question that fails is a call to StgOpenStorage(). The path in question that fails has an em-dash. If I take this em-dash out by renaming the file, then the call to StgOpenStorage() succeeds.
So my question is this: is this a known limitation with this function? Are there likely to be other Windows SDK functions that fail with special characters like em-dash? I noticed there is a call to mbstowcs() prior to calling this function, which makes me wonder if the problem is due to the code-page mapping the em-dash character incorrectly. The wchar path looks okay in the Visual Studio debugger prior to the call, so it seems weird that the function would fail on a path that the system allows.
You were right Roger Rowland, it was due to the active locale prior to the call to mbstowcs(). I fixed this problem by calling:
setlocale( LC_ALL, "" );
Prior to the call to mbstowcs(). It looks like for some reason the "C" locale doesn't support em-dash, as if I set this instead it fails:
setlocale( LC_ALL, "C" );
My regional settings are set to English (Australia).
Cheers.