Jump to content

DXF import error


Recommended Posts

This line (on its own as a test but also as part of a bigger script) compiles fine

LNR = vs.ImportDXFDWGFile('C:\DOCs\SCRIPT\LNR.dxf', isBatch)

But if I change the file to NNR.dxf (national and local nature reserves) the script doesn't compile and I get a error as below which makes no sense to me as all I change is an L to an N 

NNR = vs.ImportDXFDWGFile('C:\DOCs\SCRIPT\NNR.dxf', isBatch)

 

it even works with lower case NNR

NNR = vs.ImportDXFDWGFile('C:\DOCs\SCRIPT\nnr.dxf', isBatch)

 

NNR.png

Link to comment

Definitely a bug. Please submit it.

 

\N is the escaped version of a New Line character.

 

Somehow the parser is not looking at the string as a string, but rather is looking at it as characters and trying to find control characters and is seeing the \N as a bad character in the string.

 

Since VW only runs on Mac and Windows which are both case independent file names, you could convert the file path to lowercase as a work around.

 

Or what happens if you store the string in a variable and use the variable in the ImportDXFDWGFile instead of the string literal?

 

HTH

Link to comment

I am also curious like @MullinRJ about what happens is you "escape" the slash, but that is a bad work around in a script where you might not know what file path someone is inputting.  That will cause you all sorts of extra trouble shooting down the line versus just using lower case and filing a bug on the error.

 

Sorry Raymond, on this one I disagree. 😉

 

  • Like 1
Link to comment

All I did was ask a question. I made no statement as to the efficacy or prescription of my suggestion. I am just curious if it would work. If I had wanted to spend the time, I would have setup a test file and a dummy script and tried it myself. It's Labor Day, and I'm resting (sort of). I, like many before me, took the lazy way and posed a question rather than launched an investigation. 😜 (Disagree with me again and I shall twice stick my emoji's tongue in your direction)

 

Happy Labor Day,

Raymond

 

PS - I probably could have learned the answer to my query in the time it took me to compose this response.

  • Laugh 1
Link to comment

Adding and extra "\" does make the compiler happy but I have already changed the name to "nnr" which works fine, both options seem unnecessary. 

I was interested if my script is incorrect - I assumed the contents between ' ' would be interpreted as a string 

 

LNR = vs.ImportDXFDWGFile('C:\DOCs\SCRIPT\\NNR.dxf', isBatch)

 

Link to comment
1 hour ago, Pat Stanford said:

I agree with you. Something like a file name should just be interpreted as a string and accepted directly.

 

Forgive me, @Pat Stanford. I must now disagree with you; respectfully, of course. I believe Python does document the escape character for newline as "\n", being just one of several. Here is a list of the others – Python string escape characters. Once you know all the rules, it's easier to get it right the first time ... but it does cut down on invigorating forum discussions.

 

What I don't understand, all of the escape characters use lower case, so why does "\N" kick an error. Also, after playing around with some dummy strings, I found that "\a" doesn't print but does execute, which makes me believe the referenced list may not be complete at least as far as the VW Python engine is concerned. I suggest for anyone that's interested they test every character with a "\" before it to see what happens when a script is run, and when that string is printed.


Raymond  😉

Edited by MullinRJ
additional input
Link to comment

I still think it is a parser error. Not a bug, but a misapplication of something.  Why would the parser be looking for newline characters in a string defining a file path. It is an illegal character.  

 

And the path is inside the vs.Import function, so it is probably not a Python parser, but rather something that VW put in (probably didn't write) a long time ago.

Link to comment

Hey, Pat.

   I don't think VW put in that feature. I believe it is a Python feature for all strings. This is not a runtime error. The Python engine is flagging a problem before execution, so it is a syntax error.

 

   To look at it another way, how would Python know a string holds a File Pathname? A string is a string is a string, until it is passed to some procedure that tries to use it. It is up to the user to know how to encode strings properly, and not Python's responsibility to know what the user really wants. Basic programming minutiae. The same is true in Pascal when trying to add a single quote to a string, the only difference is Python has more escape characters than Pascal.

 

   What I don't understand, why is "/N" flagged as an error when the Python interpreter is looking for "/n"? Maybe a real Python expert could weigh in on this topic. I know just enough to be dangerous, but not necessarily helpful.

 

Raymond

Link to comment

It makes little sense to me that the python escape character is /n yet a path with /n works fine whilst a path with /N doesn't. Also I am not sure why it used to work fine on MAC but when transferring my scripts to PC it wouldn't run. 

 

Is there a reliable way to include a file path that won't get escaped by python due to any of the special characters ?  

Link to comment

Hi

I would not say i am a python expert and i also was fighting a lot with path-strings (strings and text encoding generally) in the past. Let python os-module do the job. Allow me to suggest this as following:
 

import os
full_absolut_path = os.path.join('c:', 'DOCs', 'SCRIPT', 'NNR.dxf')
LNR = vs.ImportDXFDWGFile(full_path, isBatch)

#or in one line
LNR = vs.ImportDXFDWGFile(os.path.join('c:', 'DOCs', 'SCRIPT', 'NNR.dxf'), isBatch)


This would work on both platforms. Also i saw if we are reading path from os and use it as a string, it can be necessary to normalize the path string because of some special characters to make it look good in Vectorworks on both platforms:
 

import unicodedata
path_string = unicodedata.normalize('NFC', full_absolut_path)


Edit:
In my opinion it is just "luck", that \D and \S are no special controls in python. \n creates a new line \N --> No idea, what creates that. Something that is not compatible for unicode decoding. The String is forwarded from python to VW and VW can "parse" the path with some rules but here python itself just can't interpret the code of the programmer. string 'C:\DOCs\SCRIPT\NNR.dxf' is as unallowed as a division by 0 which also put an error on the screen without any further arguments.
We could try to push a raw string to the VW function and see what happens. 
like that:
 

NNR = vs.ImportDXFDWGFile(r'C:\DOCs\SCRIPT\NNR.dxf', isBatch)

 

Edited by DomC
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...