Discussion in 'Alibre Script' started by NateLiqGrav, Dec 20, 2018.
Thanks Nate - that seems to work with my initial testing.
I'll ask the user to try it...
Update - worked perfectly for the user that it previously failed for.
Please try V3 (first post) that adds GUID. Note that required using the undocumented API ability.
Nate - just tried with one assembly so far - with the GUID option.
Traceback (most recent call last):
File "<string>", line 474, in <module>
File "<string>", line 141, in AssemblyTreeHTML
File "<string>", line 165, in AssemblyTreeHTMLGen
ValueError: Length cannot be less than zero.
Parameter name: length
Same again on another assembly - all the previous options work fine. Problems when the GUID option is chosen.
Really appreciate you taking on the challenge Nate !
Works here just fine for me on Alibre Design™ Expert Version: V21 64-bit [Build 21034] on Windows 7.
Can you tell me what Alibre Version and Windows Version?
Tried: Works here just fine for me too. On: see signature
Nate - was running it on v22 beta, Win10 Feature update 2004. I'll try again on v21 and report back.
EDIT - it works in v21 on my other computer, which is also Win10 Feature update 2004. So either something machine/install specific, or related to the beta build that I'm running. I'll ask someone else in the Alibre team to try it - that will hopefully identify if the issue is with my system, or the beta.
V3 with GUID works fine for me on v22 win 10 2004
The GUID option fails for me with build 22037 - can anyone else check...?
Works fine forAlibre Design™ Expert Version: V22 64-bit [Build 22032]
I'm now going to uninstall and try the newest build.
It works for me on Alibre Design™ Expert Version: V22 64-bit [Build 22037] Windows 7 Home Premium SP1
So looks like my PC specifically. That's a bit awkward.
EDIT - tried with a local assembly, and it works. So presumably there is some issue with files held on network (I keep most of my files on a network resource). I wonder if that is an Alibre API thing or...
Same result in v21 - the GUID option works for locally held assembly, not for a network held assembly.
If I map the network folder as a drive on my PC, then the GUID feature works.
SMB1 support was discontinued in the Win10 2004 release, which causes all kind of havoc with network file sharing (NAS drives) unless you change to using SMB2 or SMB3. May or may not be a factor, but it killed my network file access from some applications and shares until I updated my NAS settings from SMB1/2 to use SMB2/3.
Useful info on the subject : https://docs.microsoft.com/en-us/wi...oot/smbv1-not-installed-by-default-in-windows
Thanks Simon - I'll look to see if my server can do that (an old Windows Home Server).
My PC says it still has SMB1 client support, so I'm not sure that is the issue - though I'm no expert (and some of Microsoft's Windows options aren't the clearest).
Doesn't seem to be an option to upgrade the WHS from SMB1.
Even though you have client support, recent updates have closed a lot of security vulnerabilities (hence why its been superseded) and some of those updates affect basic network operation.
I too have an old Win2000 server and there is a registry key that needs adding to your mapped shares in order for them to work ...
HKEY_CURRENT_USER\Network\<Drive letter> ... add a DWORD key called "ProviderFlags" and set that to 0x00000001.
Only Windows Servers from 2012 onwards only have the option to upgrade to a newer SMB, I suspect the age of WHS, that it is not upgradable.
Also, on a side-note, if you don't use SMB1 for 15 days (on Win10 1904 onwards), windows automatically uninstalls it for you ... v. nice of it!
Simon - the mapped share that I just added works fine (and the GUID option works there).
I can access the same files by the full network path, but the GUID option doesn't work there.
Thanks for the warning about auto removal - I've disabled that (it may have become an issue for my laptop, which doesn't get used every day).
For the record I'm using GetGuidAndConstituentInformation from the API to get the GUID. I will try adding error checking to that to at least prevent the script from breaking but it will not be able to find a GUID for those files. A dev could make you a quick addon to confirm that.
Nate - are you saying there is a limitation in the API function, or what input it can handle.
The API Help says that both the possible GUID calls expect filePath, and I see the script uses Assem.FileName - are they the same thing in this context?
I have to hack my own scripts - I don't get any access to Development for this.
Separate names with a comma.