Death of VectorWorks ?

[islandmon]

Is this The Death of Vectorworks:

Following is a brief description of the file corruption which is killing an otherwise excellent app.

Don?t believe me ??

Try exporting your file as vectorscript.

>Import the Vectorscript

>error message generated :

_____________________

Line #1080: FPatByClass;

|

{ Error: Expected a new factor here. }

|

{ Error: Expected a string. }

|

{ Error: Expected ) }

|

{ Error: Did not expect this after end of statement - missing ;? }

_____________________

>Now open the text file with a text editor and search for

?objectHandle := LNewObj;?

You may be surprised to find the following ?truncated? result in the code:

objectHandle := LNewObj;

boolResult := SetVectorFill(objectHandle,

>every instance of objectHandle: = LNewObj; should read as :

objectHandle := LNewObj;

boolResult := SetVectorFill(objectHandle, hatchName1 ); **

**{The ?hatchName1? as string can be any ?hatchName(N) }.

If the result is truncated

boolResult := SetVectorFill(objectHandle,

then your file is corrupted and will eventually accumulated enough errors (as new objects are added) to cause a kernel panic !

I regret having to report this on the TechBoard but this issue existed in VW8,9,10,11 and the problem still exists in VW11.5 !

The solution is to either manually rebuild the file item by item and checking each export & import in VW or find&replace the corruption in the text export then re-import into a new VW file.

In a relatively small file with a couple hatches a few walls & columns this is no big deal. But with a normal file involving an

average project , fixing every instance of a hatch obj is a very Big Deal, indeed.

the Good Nooz so far is that v11.5 allows for this serious file corruption to be ?fixed? in vectorscript without all the

symbol coordinates defaulting to 0,0,0. The only problem is that the new compiler will import successfully only after

ignoring or corrupting most of the Plug-in objects ! Kool !

I am so very very tired of dealing with this issue. I?ve still not found a satisfactory work around. Under the right circumstances

even a single object file can ?inherit? this bug !

User since Minicad v1 with floppy security !

Mac G5, OSX 1.3.8

[Travis]

Islandmon,

We've just made a large commitment of resources to developing several "semi-custom" plansets of some of our designs. The plan is to set up a file with the basic structure complete with the linked viewports for sections, elevations, enlarged portions, etc. Based on very favorable market response, we envision taking the "basic" file and adding the interior layout and other elements as required.

This means the "original" file will be used over and over again, a little like an extremely elaborate VW Template. As improvements are made that seem more or less universal, the original file would likely be modified. We have three of these so-called base files complete. Each one has about 250 classes, 50 to 60 design layers, 17 or 18 sheet layers, about 75 hatches and well over 100 objects and symbols. We have refined a couple of methods that yield very workable "live" sections and elevations. This all seems plenty complex, even to me, but the flexibility to respond quickly (read "cost effectively") has turned out to be impressive.

I've lobbied (successfully) to base our variable-CAD plans entirely on Vectorworks. Our investment to this point is something over US$100k and will likely grow. (We're poised to purchase several more seats of VW, tho by ourselves I'm sure we're but a drop in NNA's bucket.) Based on your much deeper understanding of code-level problems like you describe above, are we contemplating business hari-kari?

What can we do to keep our core files (especially) as clean as possible from corruption? Where could we turn for reassurance that a file is/is not stable?

Please, anyone posting in response, can we leave the rants for another thread. Rather, clear explanations and realistic expectations will be much more useful.

Thanks in advance,

[ 03-28-2005, 02:52 PM: Message edited by: Travis ]

[Travis]

To further the above issue:

I exported a current, very simple, drawing as Vectorscript. I then open a new "clean" file (not one of our templates) and import the Vectorscript.

Tried it three times and got three different results. But never got an error message.

My consternation level just went up about 30 notches.

[Guest]

Travis,

Please email all of this valuable information to vs_support@nemetschek.net. While Tech Support doesn't handle VectorScript problems, the folks that do would be interrested in this information and may be able to help you out!

[RickBern]

That fpat by class thing happens to me all the time.

I've emailed files with this issue to tech and never got even an acknowledgement they would be looked at.

I completely agree. This has to be chased down and addressed.

Rick

[Travis]

I'm anxious to explore this issue:

In my variable-results file I mention above (it's a two-level deck addition made up of two floor objects, a stair object, several railing objects and a small column object that has been saved as a symbol and repeated about a dozen times), I learn the following from VS:

1) The hatch name is never truncated "off" or missing.

2) The following commonly occurs:

objectHandle := LNewObj;

objectHandle := LNewObj;

boolResult := SetVectorFill(objectHandle, hatchName6);

As does:

EndPoly;

objectHandle := LNewObj;

Since I'm utterly unfamiliar with this syntax, and since Islandmon suggests searching on "objectHandle := LNewObj;", are these occurances considered anomalies or normal.

I'm now going to undertake a similar investigation of one of our large files to see what I can learn. Any further information to guide me would be greatly appreciated.

[islandmon]

Travis,

Items 1&2 are correct ( for now : > ). However, if you continue working with the same file , adding haches, classes & wall, etc., and save it often , there's a high probability that 'SetVectorFill will it fact become truncated and there by eventually corrupting the entire file structure making it unuseable !

'objectHandle' links the hatchName:string to the Hatch.

eja

[Travis]

eja,

I've now taken time to search through one of our larger, more critical files.

I find 54 occurances of the problem you describe above. 36 are truncated, of which 30 are related to WGR'd layers.

As you predicted the VectorScript text file triggers so many errors on import it doesn't even list them all in the error report.

Additionally, I get this from the error report:

Line #10995: NameClass('Detail-Rebar');

|

{ Error: Expected a new factor here. }

|

{ Error: Expected a string. }

|

{ Error: Expected ) }

|

{ Error: Did not expect this after end of statement - missing ;? }

Would you be so kind as to explain this latter error message? Is anyone at NNA listening in here?

In practical terms, is there any "salvation" for this file other than to make as few changes as possible and keep one's fingers crossed?!

[ 03-29-2005, 10:49 PM: Message edited by: Travis ]

[islandmon]

Travis,

The file may be DOA ( Dead On Arrival ) there's nothing short of manually recoding that can save parts of it. although, the integrity will be compromised. If the entire VW community began testing , they will discover that these issues are endemic.

As for the use of a standard template file as you've 'logically' done with all the classes, layers, symbols, etc., I've tried that approach and it is definitely the road to ruin !

It magnifies the corruptions while infecting the new files like a virus.

As a User since Minicad v1 I have a huge investment to protect here, and the discovery of this C++ bug is devastating to my business to the point that I'm considering leaving Architectural Design & Engineering and moving to the construction side.

I really don't know if I want to 're-invent' myself again with some other CAD Program which probably has similar issues.

Try this little procedure:

>create a simple file with a couple walls, shapes, symbols, PIO , etc.

>Export to Vectorscript

>Import in new VW file and Export again to a new file name

do this several times in sequence. Renaming the vss eachtime.

>Open BBedit or other text editor

>Compare the scripts' text line by line

You will discover that the last 2 digits ( decimal places 14&15) of the x,y, z coordinates randomly change.

ie; 2.000000000000014 > 2.000000000000028

Also , each import will be different in some weird way. The file may also become 'randomly' corrupted and generate 'error messages' upon import. This , I think , can be connected to the C++ leakage issue.

Let me know how it goes...

I'm working on an Applescript to try to clean the vss of these errors before they can trash the file structure.

ejarmstrong

[Travis]

Thanks for your candor. This is a serious blow to my confidence in what seemed a valid business plan.

Having spent much of my "off" hours these last three days exploring this issue in our various files, I can say that the corruption is worse in 11.5 files than 10.5.1 or even 11.0.1. I haven't been as careful to start everything "new" as we moved to 11.5, so maybe some things were brought forward from 11.0.1

Some years ago I taught myself enough about one of the database manager software packages that I've successfully written several "programs" to accomplish various business-specific needs. I had thought to use a similar paradigm here: the core data changes some as needed, but the "reporting" functions can be wide and expansive and varied. But, it seems, with VW the core data gets randomly corrupted every time I generate a report.

It's clear why we went along so successfully for so many years with relatively small files and many, many projects. As our libraries of objects and symbols has grown, so have our problems.

I'm going to think very hard about this. There's nearly always more than one way to solve a problem. And I'll be very interested to learn anything more you come up with. We'd be willing to consider some type of collusion and/or compensation as appropriate.

Regards,

[jfmarch]

while we rarely use the vectorscript export, there is a way of 'recovering' a corrupt file that one of the members has on his website. go to

http://www.archoncad.co.nz/resources/resources_tips.php

and download the pdf titled: 'ow to Save a Corrupt File'

i have unfortunately had to use it and it works really well, saves a massive amount of time, and keeps you close to on track. hope this helps...

[islandmon]

Travis,

Take a typ file;

>copy & paste one layer to new file

>export to vss

>import into new file

do this with each layer in the drawing. Sobering !

Even discoverying that the compiler just doesn't recognize various parameters like 'WallBottomPeak' causing the import to fail.

Jim,

Thanx for the archoncad link . Trying to download the 200k pdf but so far no luck.

eja

[ionw]

ejarmstrong,

I have been following your posts with great interest over the past few days.

If you have the Autosave function on and set to separate directory, do you notice any difference in your test results?

I ask, because we have been fighting corruption issues at my office, and I have noticed that there are users that are more susceptible to corruption, but that 90+% of the time their backup copies of these files are fine.

Is it possible that the problems you are seeing are being caused by the saving process itself, rather than the program corrupting its open file then saving that corruption to the file?

I'd like to get your input if you have a moment.

ion

[Hunter B]

wow... and not a word from Tech support on this topic....

[nam]

Cross-posted to thread "Embarrasing VW Failures":

Ben Supnik?

Robin Peel?

Sergio?

What the heck has this all to do with normal day-to-day use of VectorWorks? As someone who draws for a living, why would you care that multiple exports/imports using VectorScript may cause corruption (see note below)?

We have been involved with the design of many buildings ranging from houses to multi-million dollar resorts using VectorWorks (back to the MiniCAD 4 days). Do we see the occasional corrupt file....sure (anyone using the program intensively would say yes). But overall, the application's stability, usability, and file quality is excellent.

VectorScript was designed as an easy-to-learn, PASCAL-based scripting language for automating processes in VectorWorks. It has grown to be a robust development platform for both NNA and many third-parties. The "Export VectorScript" function has its uses for scripters, primarily to output a non-binary (i.e. text file) version of the drawing, however I am pretty sure that it was never designed to be used for repeated export/import as you have discussed.

Your characterization of VectorWorks as "unstable", "having critical flaws", and that it's "NOT a drawing program but a programming program" just because you are seeing strangeness when attempting things outside the norm is unfair and misleading.

[ccroft]

{basically agreeing with Chris and Nam}

I've been watching this thread,the others it has spawned, and the panic it has created in some since this began.It would be nice if someone from the "Team" would explain exactly what's going on here.

Perhaps it will be a post titled "The Death of Vectorscript as an Indicator of Anything At All".

It's probable that what's being seen is a limitation of the V-Script Import/Export function (or the V-Script compiler) and nothing more. As such the solution to the problem would be to stop using them.

Myself I've used them a fair bit in writing V-script. Import is particlularly useful in conjunction with DialogBuilder. The output from DialogBuilder is quite small compared to the output from a V-Script Export of a complete drawing.

If errors are being made by export/import/compile, how is this an indicator of what is actually going on in the program core?

Regards

Charles

[ 03-31-2005, 10:42 PM: Message edited by: ccroft ]

[Travis]

I believe, Charles, that the three more or less current "crashing" threads all started before this one. Most of us, of course, remember the number of crashing threads back in versions 9.+ . . . which we all managed to survive. (All this talk of crashing makes me want to head out to the race track and watch a figure-8 derby!)

I agree that panic here would be as foolish as reacting to some prankster crying fire in the theater (that's "theatre" for those of you who speak Queen's English). . .but one might at least sniff curiously to see if he can smell smoke.

I had posted a new thread wishing to explore possible tactics to minimize corruption, but took it down because I made some declarative statements that seem accurate but I don't quite have enough experience to feel completely comfortable making.

I do know this: When file sizes start ballooning unexpectedly, when things are not in the same state they were when the file was last open, when elements drawn and modified using the latest tool iterations begin to behave erratically, a dead file is looming. If a run through export/import is also a useful predictor of upcoming problems, I for one would be grateful to have the warning.

I posted over on the VectorScript board asking if the VS text file was an accurate reflection of the underlying file. No response. I simply don't know. But based partly on the information learned in this thread, we'll exercise a little more prudence in our office going forward.

It's likely "corruption" means different things to folks. Perhaps most of us don't think about it until a file dies. Others may see corruption because the 23rd decimal-place is out of whack, even though the file will still run. It would be nice to have a reasonably accurate assessment of reality. . .a little like the hard-drive "map" that gets created when you run your disc optimizer utility. Anyone who's used a computer much knows the hard drive is gradually being "corrupted" by repeated use; and also knows how to repair it before it dies of confusion.

Mr. Armstrong has spoken loudly but I've inferred no acrimony. He's offered cogent explanation of his observations and even tried to suggest a route to a solution (the reason for his reference to the well-crafted flight simulator, X-Plane). Does he see reality clearly through the lens of VectorScript's text file? I don't know. No one has yet posted an alternative explanation. Some have had an annoying quantity of crashes and others haven't. Anecdotal evidence at best.

If this thread has done nothing more than to spur a few more to adopt a reliable back-up routine, it's likely been worthwhile.

I'm sure we'll all continue to contribute our best efforts to this valuable board. I know I'm going to spend a little less time writing and more time drawing to catch back up!

Thanks and good luck,

[michael john williams]

A bit beyond me and most probably the majority of users.

Sounds serious and what is more worrying is that there is no response from NNA - perhaps it is a bit beyond them too!

[islandmon]

Clarification:

I use Vectorscript processing as a valuable 'diagnostic tool'.

>export to Vectorscript ( Text Format)

>open the text file in a text editor

>below the 'Procedure'

>add {$DEBUG}

____

Procedure LoadFile;

{$DEBUG}

VAR

______

>save

>import the file into Vectorworks

The Debugger will run and step thru the code identifying

any anomalies. Simple...

This is NOT rocket science ! It is simply a way to see if there are any truncations in the script text file which relate to the weird

behavior of objects in your file.

As a heavily invested Professional USER since Day Uno, I really cannot afford to waste time with any of these issues. Keep in mind that I identified this situation with v9 and kept my shut about it. Except to inform techsupport.

Now I've reached the point where my work flow has come to a grinding halt. Recently one of my premiere projects refused to acknowledge OpenGL and crashed the app. Vectorscript identified massive truncations of the 'SetVectorFill'. The result is history.

I'm working to find a way out of this dilemma. Including referring to other C++ developments teams who may have resolved this problem. Why should VW developers have to re-invent the wheel if the tools already exist ?

Today is Friday and I have a long weekend ahead recovering ALL my current project files layer by layer. My office is weeks behind schedule. I do not get any satisfaction from this grotesque expenditure of valuable time & resources.

If Adobe had a CAD module , I would be in hog heaven ; > )

regards,

ejarmstrong

___________

My comment about Vectorworks not be a 'drawing program' is true. The first thing I teach my students is NOT to draw but to program inputs for the parameters then let VW do the computational work. A drawing approach is inefficient and results in unnecessary artifacts and overhead. A simple example is the use of the circle tool to draw a 'relative' circle. Rather than double click and program in the exact location and radius required. Eventually all that relativity adds up.

__________________

[ccroft]

I am questioning the value of Export/Import Vectorscript as a diagnostic tool.

It's possible that the Export/Import itself is doing the truncating.The statement that repeated import/export creates more errors leads me to think this.

As a V-Script writer, I know that the compiler has some quirks and it wouldn't surprise me if Export/Import has some too.

I've had one corrupt file, so I have little experience with this. I have had a few crashes. I have written scripts that cause crashes. At least in these cases I know why. A script with the errors that you are seeing won't cause the program to crash, they just prevent the script from running.

I read your post in v-script forum Travis. That's what lead me here. There's probably no response there because most of us are writing vectorscript, and have little experience using it as a diagnostic. Of course, anyone who writes script has vast experience with debugging their own work. This is very different than debugging the core program.

BTW Illustrator does have a CAD module....or at least it did years ago. This is how I got into CAD. I think it was a third party thing though, so I guess it really couldn't be called an Adobe module.

In closing, I'm not trying to flame anyone. It just occured to me that something else could be going on here.

Charles

[ 04-01-2005, 01:51 PM: Message edited by: ccroft ]

[Travis]

Charles,

I'm going to take advantage of your experience, if you don't mind.

Let's presume the VS-export process isn't perfect, a little like looking at the world through colored glasses. However, even with the colored glasses on, I can make out differences of another type: the sidewalk sections all look purple (because of the glasses) but some have cracks in them and some don't. The cracks wouldn't seem to be related to the color purple, even tho they appear purple through the lenses.

When I export a layer of a file and some objects have the truncated string and some don't, what does that mean? Is the export function really that random? And is that randomness really only focused on strings of a certain nature? Or is it consistently showing us everything it sees, only through a wierd filter?

Would welcome your thoughts.

[ 04-01-2005, 02:50 PM: Message edited by: Travis ]

[ccroft]

IF the import/export is creating errors I would expect them to be consistent. The problem lies in trying to detect what exactly is common to each instance.

I would say, as per your analogy, that it would be more like the "glasses" have a small chip in the lense that consistently distorts info when it's coming from a certain direction, but is noticable only when this info is needed for a certain action.

All of this, though, is a bit beyond the realm of a mere Vectorscripter like myself. I use the tools to good effect, but I really don't know how they work.

It may be important to note that while this CAD program does execute vectorscript, it does not run IN vectorscript.

[islandmon]

If you want to draw get a drawing program. If you want to do CAD get a CAD program. The former is about pixels , the later is about vectors. The benefit of VW is that it makes a sterling effort at a combination of the two approachs. Place some objects and see them render then export as images...very kool.

I'm amazed at the tone of a couple of the responses to my suggestion to run a little test on a file or two. As an experienced professional user, I can assure everybody that the problem is not in something I have done improperly ( perhaps I've pushed the envelope ). I've generated the same exact errors on a file with one object as a grouped symbol.

This is not about the vectorscript compiler. it about the file corruptions, kernel panics , memory addressing and crashes.

The challenge of vectorscript is that it's a powerful advantage and open sources the program.

If there are any problems with the VW, et al., then these boards act as an 'early warning system' as well as educational tutorials.

Hopefully everything will continue to work out for the best...

'No harm no foul'

regards,

ejarmstrong

[Travis]

Thanks, Charles, for your response.

[islandmon]

FYI,

The v11.5 CD arrived. I used it to do a total clean install. My first project was a typical survey DWG import which I've done hundreds of times before from same Surveyor source. 1/2 acre parcel some topo lines and text...no big deal.

Within 30 minutes VW crashed. Re-launch-re-open file > zoom tool>crash:

export file to VSS >import with DEBUG active > problem with text line spacing.

Look at the code & discover that the 12pt text had 12pt line spacing..ditto for 18pt @18, etc. Standard text stuff ... then noticed that after the crash my text size default was set to some huge 'unlisted' font size for the parking spaces PIO .

Took down the app.

NEVER had this type of problem with past DWG imports.

The export to Vectorscript allowed my to analyze this problem , locate ,and correct the offending issues.

eja