Petri Sakkinen
Member-
Posts
110 -
Joined
-
Last visited
Never
Reputation
0 NeutralPersonal Information
-
Homepage
http://www.4dform.com.au
-
Location
Melbourne, Australia
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
scaling while preserving positioning
Petri Sakkinen replied to David Holcomb's topic in General Discussion
Otherwise, this would be easily solved with a script, but determining which point of the polygons should be kept in place is rather difficult. If centrepoint (of the bounding box, ie not the real centroid) is OK, here's the script: PROCEDURE ScaleMultiple; { ? Petri Sakkinen 2003 } VAR active : STRING; scalingFactor : REAL; i, n : INTEGER; selectedObj : ARRAY[1..1000] OF HANDLE; PROCEDURE MakeArray (h : HANDLE); BEGIN i := i + 1; selectedObj := h; END; PROCEDURE ScaleEach; BEGIN FOR n := 1 TO i DO BEGIN SETSELECT(selectedObj[n]); SCALE(scalingFactor, scalingFactor); SETDSELECT(selectedObj[n]); END; END; PROCEDURE RestoreSelection; BEGIN FOR n := 1 TO i DO SETSELECT(selectedObj[n]); END; BEGIN scalingFactor := REALDIALOG('Scaling factor', '1'); IF NOT DIDCANCEL THEN BEGIN i := 0; active := GETLNAME(ACTLAYER); FOREACHOBJECT(MakeArray, ((SEL = TRUE) & (L = active))); DSELECTALL; ScaleEach; RestoreSelection; END; END; RUN(ScaleMultiple); [ 09-04-2003, 10:13 PM: Message edited by: Petri Sakkinen ] -
corrupted files or software problems?
Petri Sakkinen replied to L.Kools's topic in General Discussion
Ahh - time to repost one of my standard sermons: Every morning, before opening your file, make a copy of it. Keep all copies in a specific 'versions' folder. NEVER DO A SAVE AS! -
corrupted files or software problems?
Petri Sakkinen replied to L.Kools's topic in General Discussion
Ahh - time to repost one of my standard sermons: Every morning, before opening your file, make a copy of it. Keep all copies in a specific 'versions' folder. NEVER DO A SAVE AS! -
quote: Originally posted by jodawi: Often the objects will all come in as "by layer" which can map to "by class", so you could possibly just modify class attributes with a script. And perhaps the best way to do that is my free 'Cloning around' collection on VectorDepot. Once you have configured your class attributes (well, twice - for import & for export) you can save the settings to be used in new/other documents.
-
quote: Originally posted by ojardnas: please clarify.. Right. I was unclear. After the operation I described, the copy of the worksheet is just lines and text and will be exported.
-
Yes, there is. At present, they are not imported. My workaround is to select the worksheet image, say 'copy', open the scrapbook, say 'paste' and 'cut', then go back to VW and say 'paste.'
-
quote: Originally posted by Yovav: In the past (8.x days) there was such a script and it worked pretty fine. During the years, and the upgrades, the script stopped working, and the guy who developed it doesn't deal with VW any more. Yovav, Email the script to me - I can probably fix the obsolete calls etc as a matter of minutes. Well, I hope so... The address is petri@4dform.com.au
-
quote: Originally posted by Yovav: the file is opening without the "map fonts" option in the translation process, and the Gibberish is popping into the screen. It seems like the character map that Autocad uses in Hebrew is totally different from the one that VectorWorks, and other windows software, are using. Does the gibberish indicate that the Hebrew font in question is actually used? Do you have access to another Hebrew font? Does changing the font make any difference? Is it total gibberish or is there a pattern (well, there should be...) What I'm getting at is that it would be dead easy to write a script that 'remaps' ASCII codes in all text strings, ie. converts from one coding to another. A job for the local distributor of VW, perhaps?
-
Well, then you can create two text objects, name them 'datestamp' and 'filename' and use this script.: PROCEDURE DateStamp; VAR obHd : HANDLE; dateNow, fName : STRING; BEGIN dateNow := DATE(2,1); fName := GETFNAME; obHd := GETOBJECT('datestamp'); SETTEXT(obHd, dateNow); obHd := GETOBJECT('filename'); SETTEXT(obHd, fName); END; RUN(DateStamp);
-
Duh... replied to myself. [ 08-22-2003, 02:00 AM: Message edited by: Petri Sakkinen ]
-
DB, In my system, there is no font 6. You can either find out the font ID with this script: MESSAGE(GETFONTID('Chicago')); or, preferably, use fID := GETFONTID('Chicago'); and then (after creating the text, ie. instead of SetFont in the beginning) SETFONT(LNEWOBJ(fID)); SetFont sets the default font, which is not perhaps what you want. Same approach applies to size. However, there is a better approach altogether: a 'named object' ('Date Stamp') which is updated with a command. My free 'Print and Stamp" menu command at VectorDepot does exactly this when you use it to print. You can define the font, size, location, orientation, colour etc etc of the date stamp any which way and it will be updated. In addition to date, you get the filename. Not that I would use it myself: I have these as parts of my titleblock and they are updated via a menu command. This is even better... [ 08-22-2003, 01:59 AM: Message edited by: Petri Sakkinen ]
-
Well, I'll try - although entirely without experience: Have you tried font mappings?
-
Interactive snaps
Petri Sakkinen replied to Bruce Pittard's question in Wishlist - Feature and Content Requests
Ummmmm... isn't this exactly how it works now? Let's say your default settings are 'no snaps'. When you draw a new entity, you turn on (and off) each snap type as you go with a single keystroke. Or vice versa. -
Katie, I don't know how you test the program - I only use perceptive testing and according to that, many functions are much slower in VW 10. However, I have sent a sample file about a certain (raster image-related) issue to Paul Pharr some weeks ago - in that case, it is not about perception but something you can see (flickering while-U-wait, wait & wait). Now, if you add the speed loss of VW 10 to the speed loss of OS X, sluggish is an understatement. I don't use OS X but have still decided not to upgrade to VW 10 because of loss of speed and also because of some bad user interface decisions. While there are some attractive new features, for everyday work I would need to stick to VW 9 anyway, so spending big for a couple of fancy features and endless hassles do not appeal at all.
-
As most DTMs, that of VW works out contours from the TIN-model (triangulated irregulard node) which 'simply' (the algorithms I have seen are anything but simple) connects the dots (3D loci or 3D poly vertices). What happens between points, is not known and linear interpolation is just as valid as any other. For the human brain (at least that of an experienced landscape analyst), it is possible to 'see' (=guess) the 'trends' of landforms, based on what is 'above' and 'below' any contour, but I'm not sure if I would like to have a stupid computer making these intuitive guesses - after all, the computer has not made any geomorphological field trips, done orienteering or tried to find wild mushrooms with a topographic map. So, to make the point: any other interpolation would try to 'add' something to the data. A good surveyor takes his/her spot levels in an intelligent manner and that certainly helps. Terrain modeling is not an exact science in any case. And now for something completely different: in addition to TIN models, there are also DTM engines based on the raster concept. With a raster (grid) it is indeed easy to traverse the data set along grid lines / raster cells and do 'trend' type calculations, more complex imterpolations / extrapolations and even 'typology' analyses. This, however, requires huge data sets, compared with the TIN approach. Whoa - I try to sound like an expert! That I am not. Definitely not.