_c_
-
Posts
2,434 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by _c_
-
-
Robert, it needs an active edit of the search string field AND this string to be different than the stored prefs. It's choking on evaluating the stored prefs, apparently.
Joerg, beruhige dich, bitte. As long as this isn't fixed you can achieve your replacement simply editing the search string in any fashion, just make it different, eventually edit to anything different, close the dialog, re-launch, edit it to your needs.
Don't use the proposed string showing in the edit field upon launching the dialog, you MUST change it.
orso
-
both help and the forum's have been totally inadequate in assisting
Isn't it unfair that you claim this forum to be "totally inadequate" when as far as I can see you have only three posts on it.
In the forum there are great many top experienced users, from any corner of the world and any discipline, always answering questions, from basic to really tricky ones. The NNA engineers answer too.
Ask. You won't be left unanswered. As long as you don't know the VW terminology you'll find difficult to search. That's where asking others will lead to immediate solution. The "machine" cannot bridge such en-passes.
Personally I find the help system totally adequate.
Mind: in the VW environment "object's layer locked" doesn't have any meaning. A "layer" is a container, objects on drawing are contained by it, not vice-versa. "Locked" is a term that we'd use f.ex. for preventing editing (right-click on an object, contextual menu, lock it). A layer cannot be locked, is a particular container-object with a place on its own in the whole drawing (=document) tree, see explanation of the Blind Expert.
Searching a sentence like that will bring you a huge amount of entries since layers are more or less the basic item in this application, this word would appear countless times. You need to refine it. You'd do the same on a google search.
orso
PS. I added now a file where you find an executable script which will allow you to find/rename any kind of object. You might have a large file and know not where the object to be renamed is.
For basic renaming actions this script will help resolving this naming conflict and let you work -for example- with the window object from the tool palette. The file works from VW 2011. Since you didn't post your specifications, I assume you have the latest version.
-
Bruce, when you experience these strange shifts in VW 2011, it always helps cmd +5 (top plan). Some planes of the singular objects might make you troubles. Worth trying if this is the case.
orso
-
I don't understand what it does, the manuals are not downloadable nor is there any description in detail. Anyway, as far as I can see, it's VS and no SDK, so they can do nothing more than I can. For that money I wouldn't ever buy anything, BTW, not when I can do it myself.
I just need to merge this kind of functionality into some other stuff I have for generic project management, it should be no problem at all. Only need time, something more than 2 hours before going to work.
orso
-
Petri, tell me exactly - privately, ungehemmt geek - what's not working. Everything should be fixed aside of a minor OIP regen issue .
But I can look into it when I am on holiday... :sick:
Aye, I dislike excel too, found yet no real need for it.
orso
-
Petri, it should work. I did test the VS access throughly and the last I saw was absolutely working fine. If something doesn't work again we'll find out.
Should also work like a charm from inside PIOs. You need unfortunately either FileMaker 11 if you want a light life, or some really heavy hacking. But I got it going even on FM 8 (with Major Pain). Just keep that FM file constantly open. That's the drawback.
Tested also on RagTime and Excel. I didn't get it to work on Excel Mac because the version that I scratched up (4 Mac 2004 licenses, relicts from a bankrupt office) didn't support ODBC. Should try still on PC in the office. I am sure is absolutely no problem.
Soon we could give it a go together. When I re-emerge to life from this nightmare here at work.
orso
-
Bryan, a good way is to use the Issues combined with Issue Manager. You need to have prepared title blocks for this to work well. See documentation for Custom Title Blocks.
Then I refine this using worksheets parsing Redlines (might well be a misusage). The worksheets display a filtered amount of Redlines. Please see screenshots.
Is rather simple: whenever you add Redlines in your source documents, they list then automatically in the sheet layers displaying them. The worksheets are local and parse these data filtering by layer.
This way I can also keep a total log of all smallest changes for the whole project.
One day I'll make myself the total revision parser, project wide, through ODBC. Which is among the best 3 features of VW 2011, on my opinion.
orso
-
We are searching advise for an anomaly leading to extremely slow "save" when saving VW files to a Window 2003 server.
The save action will take about 1 minute each 10 MB.
This occurs only on "Save", but NOT on "Save as", IF the file thus created is new. If the file overwrites, then it's slow. If it doesn't overwrite is extremely fast.
We tend to believe that the slow down occurs upon trying to delete the temp-file created by VW. Perhaps this deletion is delayed for some reason by the server. A time out to be waited for?
The issue won't occur upon saving PDF, Photoshop files, no matter how large. But it seems to occur in minor extent upon saving Illustrator files or excel files.
The network is Gigabit fast. The clients are either WinXP or Win7. Both show the same identical issue.
* we excluded any interference with virus scanner,
* tested all permissions, both server-side and client-side
* changed all ethernet cables,
* changed network card,
* added a second network card,
* changed the switch,
* excluded all clients (20 incl. printers, fax....) re-adding them one by one.
* removed all hard disks but the main one and re-added them,
* disabled indexing on the involved folders
* disabled shadow copies on the server
+ a number of things that our PC admin did, and I don't know what it was.
Please don't tell me upgrade to Mac. I know.
I believe that we could have bought many many Mac servers with the money we spent in fixing all issues that these Win server had and will always have.
orso
-
Ciao Justin,
There is nothing one cannot learn. It's just a matter of time and endurance.
The problem is that -as Pat implied- this is not a process you get done in a few weeks. I calculated I would need some three months full immersion only to get through the very basic of C++. It's not only C++. You'd better learn C first. You need to fetch some deep knowledge of the systems too. I began many times already. Next time I'll be unemployed....
Personally I have a deep dislike of learning by videos. I prefer by far reading and searching alone. A good bibliography to get started, that's the thing. But I come from an educational system based exclusively upon books. Italian conservator, a mix between an architect and an archeologist, a detective for old buildings. People in this field are few and characterized by a boundless curiosity and a weird lonely analytic approach. The research is the target, for us.
-
Justin,
please edit that routine: it is awfully dangerous.
I don't understand what you are trying to do there, part of the code is missing, you seem to wish a recursion, but this is just not the thing. Don't publish things if you are not sure. Some might use it and have troubles, which is certainly not what you wish.
Also you can get rid of the "moveTo" in my sub, you can use "Line(1, 1);"
which, being relative to whatever position the mouse had, never poses problems.
If you want to pass a group of profiles, you simply loop down the objects one by one.
orso
-
LOL!
Assembly, please don't get offended, but... learning C++ by videos from Vlado would mean we to renounce to him completely for years. All the years you'd need to learn C++ and have questions. He'd be only busy doing your "5 minutes" videos.
orso
-
We want to coordinate better Vectorlab with the Developer wiki. We will soon remove a lot of stuff from Vectorlab and link directly to Dev. Then we'll use Vectorlab as "sandbox", open to anyone who wants to write about Vectorscript, while the Developer wiki will keep on being the high-end resource for third-party developers, the place where official descriptions are stored and maintained.
We wish to have a place where things are secure: the Developer wiki.
We also need to have a place where things are wild: Vectorlab. Now we can have both.
We are now in the position to do this, since the Developer wiki has been opened to public editing. Developers are able now to log in and contribute. This is a silent historic event that -for me- marks a new era in the relationship between NNA and his users. Us.
As to the complaint about the difficulty in learning VS...
Vectorscript is a complex and powerful environment. Getting started IS ALREADY possible. Has always been. But won't be ever easy as you expect it to, no matter how many articles you'll have.
In the early 90es I learned VS going by bus to the building site before down. With a Pascal book written in German (I am not German) and no manual. And no internet access. Where I lived -east Berlin- nobody had a telephone. There were no telephones at all. So we arranged a weird home-made telephone system shared by many. Every now and then, once a month or so, one could hope for an internet connection. Which was very expensive. I used this seldom connection to read the vectorscript list. There I learned the basic of Vectorscript from NNA engineers and other scripters. They are still all there, with few exceptions.
The vectorscript list was at that time the only available resource.
Years later I had the chance to jump in and help creating Vectorlab. I paid thus back the help I got in those early years sharing my knowledge and organizing other's.
Don't expect to be spoon fed. You won't ever have such a hard time in learning VS as the old scripters had.
orso of Vectorlab
-
Scott, you work as I do.
For you is better to let that option unchecked upon conversion.
The method we use is much faster when you need to publish things. Just override the current document class and all viewports follow.
For your knowledge, in our workflow Design Layer Viewports are useful for working files, but never for publishing files.
You will prefer to leave them out of your conversion for now, but experiment with them later in your working files. They are more or less like layer links but with a crop and a -devilish- class management (just for you to figure what they do).
If you have Design Layer Viewports in publishing files the attribute management gets so complicated that not even me -user since ages- comes out error free from it. They are very powerful, but not efficient when you must care about appearance (say: different color coding in the plot files, such as we often do in Europe).
happy upgrade, you'll love it
orso
-
Yes,
ovWSAutoRecalculation can now be made off (flag 85) or SetWSAutoRecalcState (was introduced by VW14), and this does make a huge difference. Still, text or xml files would be faster, a lot faster.
{ ... } SetObjectVariableBoolean(worksheetHandle, 85, FALSE); { auto-recalc off, or performance issue } { do something 15000 times, or better, as many as max ws lines! } SetObjectVariableBoolean(worksheetHandle, 85, TRUE); { restore recalculation for the worksheet }orso
-
Jarno,
spero non sia troppo tardi, ma nel caso tu legga altre risposte...
you might wish to contact Joel Sciamma of www.inventors-emporium.co.uk. He develops in VS a large package for analyzing big lots of landscape data. I am sure he'd be able to hint you to some optimizations specific for your needs.
I don't know what you need to do, but 15000 coordinates in half an hour is far too long. I have a script for other things parsing max integer limit (32767) of string count and it takes max 3-5 secs to do its job in a loop, including displaying into a list browser the whole of it.
buona fortuna
orso
-
Assembly, you are using a variant of my sub for 3D object creation. That routine I use since years, in many PIOs. If used properly it doesn't create problems.
A couple of notes:
- If you care about origin, be aware that while you are in a PIO you can't see the user origin shift. The PIO is in its own world. Don't mess up with origin by script.
- There are differences -and there are always been- according to how you run a script: by palette, by menu, by applescript or if it's PIO. These differences are on routine-basis, if you use BeginContext, but also and particularly the compiler.
- PIOs are also different in the sense that they have multiple regens, the code doesn't run only once, it can run many times.
You need now to create a basic pio with only an alert. Please experiment with all various options:
* click on tools palette
* placement on drawing (IsNewCustomObject)
* reset existing instance by parm change (simplest user edit)
* duplicate
* copy and paste in a new document
* wall insertion
* regen coerced by wall changes (this gets rather tricky on texturing)
* placement with CreateCustomObjectPath, according to the running VW version.
* has profile groups
* is event enabled or not
* has reset on move/rot or not
* has reset on other special events or not and here you can spend a long time in searching for all possible quirks of events/special props according to the parent container.
* ....
These are some of the things you need to check for avoiding problems.
You can't transfer the code of a menu straight off to a PIO. I don't see any "IF GetCustomObjectInfo(gPioN, gPioH, gPIOrecH, gWallrecH) THEN... ". You need that in order to avoid the code to execute when a forced regen is not needed, or wish to execute something else.
So don't look at the memory allocated, is none of our business and we can't do a thing about it anyway. You need to look at your handles.
The code needs to change, Assembly. It doesn't help you to stick to it, because is not OK.
Please compare the original H_Create3Dobj from Vectorlab with your one.
You can observe that
* you create a temporary line but don't delete it
* you assign this extruded line as result to Create3Dobj, but actually don't really use it. You also assign the handle before inserting the new obj in the extrude. But this doesn't harm, because....
* you use a global variable htemp as result for CreateDuplicateObject.
So actually you have no idea where your extrude is going, what it is (it's a line with some other shape) and which is the handle, global temp (* fear *). You don't need that function, but to make problems, with your changes.
FUNCTION Create3Dobj(h: HANDLE; z, dZ: REAL): HANDLE; BEGIN IF h <> NIL THEN BEGIN BeginXtrd(z, dZ); MoveTo(0,0); LineTo(1, 1); EndXtrd; Create3Dobj:=lnewobj; htemp:=CreateDuplicateObject(h, LNewObj); { DelObject(FIn3D(GetParent(CreateDuplicateObject(h, LNewObj))));} END; END;{ Orso **************************************** } { creates an extrude from a HANDLE h, preserving the original h. Returns a handle to the extrude } FUNCTION H_Create3Dobj(h: HANDLE; z, dZ: REAL): HANDLE; BEGIN IF h <> NIL THEN BEGIN BeginXtrd(z, dZ); Line(1, 1); { just draw something for creating an extrude container } EndXtrd; DelObject(FIn3D(GetParent(CreateDuplicateObject(h, LNewObj)))); { places a Copy of h in the extrude and Deletes the line } H_Create3Dobj := LNewObj; END; END; -
Assembly, does this out of memory only occur on inWall objects or also outside?
I also looked into the code and agree with Joshua: you play with fire with the variables, too many possible NIL handles un-dealt with. Never use globals in functions which you mean to recycle. Not even a genius can foresee what happens if something goes wrong.
I'd search for a wrong handle. Not necessarily a NIL handle. Simply a wrong one.
Anytime you use CreateDuplicateObject in inWall PIOs you need to counter check handles to obsession. That can cause you problems.
I also had a pio which every now and then when inWall AND not top-plan would enter a loop of duplication of the wall where it was inserted. A wrong handle, simple as that. Caused thousands of wall duplications in few seconds. Sloppy scripting highest level. LOL!
FUNCTION D3_Stud(hProfile: HANDLE; FrameLength: Real; Pitch: Real; z: Real): HANDLE; BEGIN; TagString := 'Stud'; hTemp := hXtrude(hProfile, AdjustforAngleHypot(FrameLength, Pitch)); RotateZ(hTemp, 90); MoveObj_Length(hTemp); MoveObjZ(HTEMP, Z); D3_Stud := hTemp; END;
o
-
It surprises me too. And is very well published. And is there now since more than two years.
Robert, the problem there are the edit rights. Nearly nobody outside NNA has edit rights. There are only two external editors. Look at the wiki user's list, please.
Since I doubt that NNA engineers have the time -or wish- to produce more examples, more documentation, I guess the only possibility is to open up the wiki for editing at least to those who on NNA opinion would be capable of contribution. You know well who they are. Ask them to file more documentation.
If they can post mails helping others, they can also file durable entries in the wiki. And if their entries are not perfect, someone else can correct, that's what a wiki is for.
If the wiki had traffic nobody would dream of looking elsewhere.
orso
I'm shocked that no one in this discussion (who is seeking VS or SDK support) has mentioned the Vectorwiki:http://developer.vectorworks.net/index.php?title=Main_Page
If you're a serious VS or SDK developer, this needs to be one of the tabs on your home page.
-
The "Task".
After "BIM".
Insist. It might take a few seconds patience before you discover it...
-
I also wish this could be done. It is
* awfully tricky
* terribly complex
still, I wish it was possible. And not only for DVLPs, also for any kind of viewport.
orso
-
You'll love it, Kevin.
VS is great power. It allows you to work less while producing like you were a team.
Login in the VS-list (not the forum here, which is too basic), you'll find many advises and many friends. Nearly all questions have been asked there before. Someone will always help you. Read all, read the history.
welcome, Kevin...
o
-
provide audio/screencast comments and examples for us struggling mortals.
That would take huge movies. It takes very very long to develop a well thought script. Months, if you do it in your spare time. We all have scripts being developed since years.
It is really not possible to do what you ask. The things you must know are so volatile according to the script's target and area of influence, that you simply can't document all.
The basic is described in the official documentation, in the developer list you'll find comments about the quirks (BTW, the current developer list reproduces a previous list from Charles Chandler, state of 2008, with authors and time of the comments removed, so if you wish to know when a quirk was valid and if this is creditable as info, please see VSFR by Charles (archived, or so it seems), there you find the missing infos ).
On Vectorlab we tried to offer advanced advise over some hard-to-learn topics. You'll find many good advises. Is purest VS-freak only.
The problem is that
* the scripters/programmers capable of writing such articles are very very few
* of those, really few see any advantage in the selfless sharing that a wiki implies, or don't mind it.
I can count these few on one hand. By name.
Mind, most scripters are a proud selfish egocentric lot searching for the immediate kick of public acknowledgement. This isn't given in a wiki. A wiki is give-only. It takes that kind of mind, to write there, to wish to share. No return no thank-you back.
And BTW did you ever think of a second of acknowledgment to the -for you- nameless engineers writing and developing examples, thousands routines. How come this is all taken for granted.
Most of the old scripters didn't have that documentation, the overflow of documentation that you have now.
Please try it out, you'll see that you have all you need to get going, it will be nice. Even if not without moments of frustration. But this is why we love scripting, easy to achieve things aren't as nice.
orso
-
Dear moderators, please move us to the VS forum, we'll get into boring details now.
Well done, Kevin.
Now, considering the largeness of the VS documentation, would you call this "many errors"?. Not.
1- not error, lack of updating documentation, please see old versions of VW
2- not error, just inconsistent value in example file
3- not error, see Miguel
Stay fair. Error is something else.
Something more. What you actually wish is to work by includes. Easiest configuration:
* save a textwrangler file with your script in you User/Plug-Ins folder. Use file suffix ".px" or ".vss". Please read the documentation about "Includes" for the difference. I advise you to name your text files with a suffix such as "z" because they will list in the script editor, which is boring.
* in the plug-in editor select your tool/command, edit it
* remove all code there, add this line {$INCLUDE z_myScript.px}. This tells the compiler to search for an include file in the same folder as the plug-in. For the compiler this could mean any of the three folders: application, user, workgroup.
* save and close
* now activate the compiler mode: Tools > Scripts > VS Compiler mode.
Use your tool/command and it will load the script from the text file. You don't need to copy-paste between TW and script editor any longer.
This is very very easy. It will only get complicated when you need to cover different paths, platforms, with the same include file or aliases thereof. I mention this, because you might land there.
Next step: find out how to use a common folder for ALL your include files.
orso
-
Never heard of such a thing. How weird.
Please delete your user preferences:
* quit Vectorworks
* open the folder containing your user preferences, in your case it should be named "Vectorworks/12/Settings". I don't recall the path for XP, I am at the Mac right now.
* delete the file "SavedSettingsUser.xml"
* restart Vectorworks
Now look if this fixed.
orso
VectorScriot or ...
in Vectorscript
Posted
Me.
Time, lack of it, is the only hindrance. Wish me to be unemployed again or to have a new little child justifying some time off work.
VS could be frozen on my opinion and I would go for anything new there was.
orso
"Now, bring me that horizon" (JS)