Existing VBA add-ins have started to fall over on this line if the filepath is longer than 126 characters. Shorter file paths are not an option, unfortunately.
Set ImageControl.Picture = LoadPicture (FilepathLongerThan126CharsErrors)
Runtime Error '75' (File/Path access error)
The error does not occur if the file path is shortened to 125 characters.
We tried to set the RegKey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled to (1) but to no avail.
Machines that have not yet had the Windows 10 1903 update don't seem to be affected. The problem occurs mainly on Surface Laptops so far but also a few other PCs.
Possible workarounds are listed below:
You may copy existing images into the AppData subfolder to make a path shortened.
Use the ShortPath property which returns the short path used by programs that require the earlier 8.3 file naming convention.
Yes, thank you Tim and Eugene. I am now working with the 'ShortPath'.
However, the problem is still that the behaviour of this method has changed with the Windows 1903 update (from allowing 260 characters to now 126). There must be quite a few people out there scratching their heads why their codes are failing seemingly at random.
Thanks anyway. I'll put an error trap to feed the ShortPath through when needed.
Related
Beginning in build 2102 of MS Word, a very elaborate document that I have created no longer works properly.
My form makes extensive use of FormFields. Starting with build 2102, it appears that Word VBA is not able to properly execute this command:
ActiveDocument.FormFields("MyFieldNameA1").Result = 100
if the field in question has fill-in enabled set to off. It instead changes another, seemingly random field in the document.
There is no way that this is intended behavior.
You can work around this via:
ActiveDocument.Bookmarks("MyFieldNameA1").Range.Fields(1).Result.Text = 100
This is a long-standing approach to programmatically inserting strings longer than 255 characters into formfields. Works just as well with shorter strings.
Build 13801.20808 of version 2102 Word is affected, however this was fixed by Microsoft in at least build 13801.20960. Just for documentation as I just came across this problem.
Here is the problem I want to solve:
Let's say I have a collection of 30 000 files (videos, images, sounds, etc...). And let's say I need to move/rename them a lot (including sub and parent folder). Not to mention those files will move from different OS (win, osx, linux(NAS) ) in a near future.
My problem stands when it comes to keep a link references to those files in my personal notes (evernote and blog mostly). Since URLs will broke all the time, I was thinking of adding a GUID/UUID in the file name (only for the file I need to refer to). this way, I could always do a search and find my file no matter where it is.
But GUID are quite a big string (36 characters if I've counted right). I don't need a world global uniqueness for my file. Just enough uniqueness to make a difference between maybe less than 10 000 reference (in my hole life ^^).
So I was thinking of using only the last 12 characters of a GUID string and add it to my file. Keeping the same string in my notes. And in case of collision, that would not be a problem because I know my files well and figuring out witch one is the right wouldn't be a problem.
Could this works?
Could I use an even smaller string ? (like the first 8 characters)
thx for your help.
Best.
William
files_array=( $(ls directory/of/files) )
for i in "${files_array[#]}"
do
var=$(echo $(uuidgen -r | cut -d'-' -f 5))
rn $i $i"$var"
done
I'm trying to use Twisted in a web-app, and I'm coming across an interesting issue. I'm very new to Twisted, so I'm not sure if I'm seeing a bug in Twisted, or if I just am not using it correctly.
Theoretically from the example, a File resource object can be use to both serve files from a directory, as well as provide the directory listing. So assuming I have the variables (port, reportsDir) defined elsewhere before the code snippet, I do the following:
rootResource = Resource()
rootResource.putChild("reports", File(reportsDir))
reactor.listenTCP(port, Site(rootResource))
reactor.run(installSignalHandlers=False)
Now, when I access '/reports' on my host I get a message "Request did not return bytes" in my browser with a bunch of stuff that was obviously produced by twisted, but also contains a print of a u'.....' string literal, which in fact has the directory listing in it. So the DirectoryLister is obviously creating the listing HTML, but it isn't seeing as valid by something in Twisted. It doesn't seem to like the unicode string; which was in fact produced by Twisted itself.
Do I need to set some other configuration item to get it to convert the unicode string to the necessary bytes object (or whatever), or some other approach?
Many thanks,
-D
Well, it seems like the issue is that Python will promote any string to unicode if any source string on a format was unicode. In my case, "reportsDir" was unicode because it came from a XML file, and that set it down the error path.
Changing the above line:
rootResource.putChild("reports", File(reportsDir))
to:
rootResource.putChild("reports", File(reportsDir.encode('ascii', 'ignore')))
fixed the issue. I would however suggest that the Twisted developers do a check for unicode in the constructor for File, or in the DirectoryLister simply check for unicode, and if it is then return the ascii-encoded version.
i want to use a windows API to check a file/directory is hidden or not .
GetFileAttributes may the best choice. but when i check the FAT "C:\", it's return 0x10.it's looks work well. but in NTFS "C:\" it's return 0x16, maybe it's show that "C:\"'S Attribute is "system", "directory",and "hidden". so the problem is here, why it's return hidden? in fact it's not hidden.
would you please give me another API to check the windows file system's file/directory is hidden or not?
thanks a lot.
GetFileAttributes has a BIG BUG, to see it try this simple code:
ShowMessage(IntToStr(GetFileAttributes(PChar('C:\.MyNonExistantFile'))));
It shows that GetFileAttributes has return 32 in decimal (since file does not exists it is a BUG, correct return value must be -1).
Also you can try it with this:
CreateDir('C:\.Anything');
ShowMessage(IntToStr(GetFileAttributes(PChar('C:\.Anything\MyNonExistantFile.TXT'))));
It is related with files and directories starting by a period (.) symbol.
Note: FileExists also returns true in that situations (and file does not exists).
I set the culture to Hungarian language, and Chr() seems to be broken.
System.Threading.Thread.CurrentThread.CurrentCulture = "hu-US"
System.Threading.Thread.CurrentThread.CurrentUICulture = "hu-US"
Chr(254)
This returns "ţ" when it should be "þ"
However, Asc("ţ") returns 116.
This: Asc(Chr(254)) returns 116.
Why would Asc() and Chr() be different?
I checked and the 'wide' functions do work correctly: ascw(chrw(254)) = 254
Chr(254) interprets the argument in a system dependent way, by looking at the System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage property. See the MSDN article about Chr. You can check whether that value is what you expect. "hu-US" (the hungarian locale as used in the US) might do something strange there.
As a side-note, Asc() has no promise about the used codepage in its current documentation (it was there until 3.0).
Generally I would stick to the unicode variants (ending on -W) if at all possible or use the Encoding class to explicitly specify the conversions.
My best guess is that your Windows tries to represent Chr(254)="ţ" as a combined letter, where the first letter is Chr(116)="t" and the second ("¸" or something like that) cannot be returned because Chr() only returns one letter.
Unicode text should not be handled character-by-character.
It sounds like you need to set the code page for the current thread -- the current culture shouldn't have any effect on Asc and Chr.
Both the Chr docs and the Asc docs have this line:
The returned character depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class. TextInfo.ANSICodePage can be obtained by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
I have seen several problems in VBA on the Mac where characters over 127 and some control characters are not treated properly.
This includes paragraph marks (especially in text copied from the internet or scanned), "¥", and "Ω".
They cannot always be searched for, cannot be used in file names - though they could in the past, and when tested, come up as another ascii number. I have had to write algorithms to change these when files open, as they often look like they are the right character, but then crash some of my macros when they act strangely. The character will look and act right when I save the file, but may be changed when it is reopened.
I will eventually try to switch to unicode, but I am not sure if that will help this issue.
This may not be the issue that you are observing, but I would not rule out isolated problems with certain characters like this. I have sent notes to MS about this in the past but have received no joy.
If you cannot find another solution and the character looks correct when you type it in, then I recommend using a macro snippet like the one below, which I run when updating tables. You of course have to setup theRange as the area you are looking at. A whole file can take a while.
For aChar = 1 To theRange.Characters.count
theRange.Characters(aChar).Select
If Asc(Selection.Text) = 95 And Selection.Text <> "_" Then Selection.TypeText "Ω"
Next aChar