Petri

No scripting needed - you can just use the worksheet (report) to get the locations. Depending on the design of symbols, different functions are needed, but I would suggest a design where =XCENTER and =YCENTER provice correct results. Labelling is best handled with a data record, so you can show the numbers on the drawing with linked text.

Quite possible and very easy. Use GETPTL(x1, y1, x2, y2) to retrive coordinates and to define the text location, then TEXTORIGIN(x2, y2) and CREATETEXT([coordinates converted to text with NUM2STR, separated with CHR(13)]). For clarity, convert first to string variables. Better still, make it a PIO (with a different approach and code) and you can move it, with coordinates automatically updating.

Hear, hear! The same applies to associative hatching - if I say 'hatch', the odds are overwhelmingly that I want to use the hatch I used before. And when I say 'edit hatch' (in the attributes palette), the newly edited is likely to be the one I want.

quote: Thought it was a problem of your partners solved by using the Apple mouse?Yes - she had real pains, requiring medication and days off, mine were mainly frustration, although after a long day even my hand and wrist were tired and achy. quote: What's that suppose to mean?Well, it was an attempt of humour - aren't architects always blamed for form over function? I know I am!

quote: Originally posted by alanmac: Can't see this myself. Lucky you - the two years I worked with a PC and two-button mice (bought several) were a constant pain. quote: Apples dogged form over function attitude I take you are not an architect... But, hey - whatever works is good. I just find Apple's current mouse very comfortable and relaxing as it allows any hand position or clicking method - even with a glass of Scotch in hand (it is quite late here and Saturday.)

It seems that nowadays one can indeed get the z-values of symbols with a script, but still not with a worksheet. A script can write to a worksheet, - but it won't be a database report. A script can also write to a record, but not automatically. A PIO would do both (say, one that places a symbol), but that is a fair bit of work, to get the user interface right. And now, just for curiosity: what sort of data exchange you have in mind? quote: Specifically I want to be able to create a database worksheet with this coordinate information for export into 3D visualization information. One would think that there are other ways than parameter export/import, but obviously the receiving program can be controlled by parameters.

quote: Originally posted by Kaare Baekgaard: By the way: It would be nice, if I were able to replace 3D loci with symbols Not quite sure if this will work but give it a go. It is a generic utility I have used in 2D drafting for years; just added support (?) for 3D symbols, but did not test or even check the syntax. code: PROCEDURE sel2syms; { ? Petri Sakkinen 1998-2004 } { This macro replaces selected objects on the active layer with instances of the active symbol } VAR i, n, objType : INTEGER; x, y, z, a : REAL; xi, yi, zi, ai: ARRAY[1..1000] OF REAL; theSymbol : STRING; obHd : HANDLE; BEGIN theSymbol := GETSDNAME(ACTSYMDEF); IF (theSymbol > '') THEN BEGIN obHd := FSACTLAYER; i := 0; WHILE obHd <> NIL DO BEGIN i := i+1; x := 0; y := 0; a := 0; z := 0; objType := GETTYPE(obHd); CASE objType OF 9 : GETLOCUS3D(obHd, x, y, z); { found a 3D locus } 15 : BEGIN { found a symbol } GETSYMLOC3D(obHd, x, y, z); a := GETSYMROT(obHd); END; 17 : GETLOCPT(obHd, x, y); { found a 2D locus } OTHERWISE HCENTER(obHd, x, y); { found something else } END; { case } xi := x; yi := y; zi := z; ai := a; obHd := NEXTSOBJ(obHd); END; IF YNDIALOG('Delete selected objects?') THEN DELETEOBJS; FOR n := 1 TO i DO BEGIN SYMBOL(theSymbol, xi[n], yi[n], ai[n]); IF z <> 0 THEN MOVE3DOBJ(LNEWOBJ, 0, 0, zi[n]); END; END ELSE ALRTDIALOG('You must have an active symbol'); END; RUN(sel2syms); {-------------------------------- Petri Sakkinen panta rhei information technology 19/125 Oxford Street Collingwood VIC 3066 Australia ---------------------------------} [/code] Made a couple of small corrections. Hmm - should I even test it? Right - seems to work. [ 10-08-2004, 07:09 PM: Message edited by: Petri ]

Not only live sections, but ones where solid objects are actually solid (and I don't mean only solids, but also slabs, walls, roofs, extrusions etc. - anything in 3D that has a fill or texture. Ideally, there would also be two line weight definitions - one for, say, perspectives and axos, another for plans and sections (plan being a horizontal section.) The implementation might be best handled with viewports, by adding a section line that would work in the same fashion as crops, with the option of a 'double line', ie. the depth of the section. Sections should also be able to viewed in perspective. In the good old drawing board days I did sections in scale 1:20, sometimes with the background in perspective. Now, in some professional fields, the required section planes are not necessarily vertical, so obviously the section line needs to be definable in any projection of the viewport. 'Cascading' booleans for these live sections would of course be hugely nice....

And, NNA, while you are implementing Mike's wishes (all seconded): one should not be able to snap a dimension to a witness line of another dimension.

Hey, APE Design, were the default values entered before placing the symbols? Changing defaults does not affect existing instances. If the instances predate defaults, don't panic. Use custom selection to select all instances of the symbol, then in OI say 'Replace'; use any symbol you have and then repeat 'Replace' with the actual symbol. This does not work if the symbols are in walls, but I think I have a script somewhere that does the job.

This is for reversing vertices of a path PIO, but you should be able to modify it to work on 3D polys - just remember that the first vertex is 0, not 1. Synopsis: - read vertex coordinates into an array - use the array to reposition vertices in the reverse order ------------ PROCEDURE ReversePath; { ? Petri Sakkinen 2002 } VAR i, j, n : INTEGER; x, y, t, r : REAL; obHd, pHd : HANDLE; vx, vy : ARRAY[1..100] OF REAL; ok : BOOLEAN; BEGIN obHd:=FSACTLAYER; pHd:=GETCUSTOMOBJECTPATH(obHd); n:=GETVERTNUM(pHd); FOR i:=1 TO n DO GETPOLYLINEVERTEX(pHd, i, vx, vy, t, r); FOR i:=0 TO n-2 DO SETPOLYLINEVERTEX(pHd, n-i, vx[i+2], vy[i+2], t, r, TRUE); END; RUN(ReversePath); ---------------------

Did anyone who lost viewports by any chance change layer scale with 'all layers' option? If so, do it again, and change the scale to 1:1, after that, change the scale of design layers by selecting them in the Layers dialog; in the Scale dialog do NOT say 'all layers.'

Hear, hear! It is all too easy to say 'buy the fastest computer available', but in the real world, few people are able or willing to buy new hardware every few months.

quote: Originally posted by Kevin: It has been my assumption that programs running under Classic will run slower. Are you saying that VW runs faster under Classic emulation than under native OS X? How exactly do you have this set up? VW runs a lot faster in Classic mode, not quite as fast as under 'real' OS 9, but still heaps faster than in OS X. OK, I have only a G4/800 with 768 MB of RAM, but with OS 9 that had plenty of power. So, I made a copy of VW 9 (application itself) in the VW folder and in 'Get Info' ticked the 'Open in Classic Mode' box.

The main advantage of Jaws against print dialog 'Save as PDF' is that it uses round pens; also there is some control over the quality (and therefore file size.) Against Acrobat that Jaws uses round pens without a PS printer - and price.

As comes to occupational health, Apple's one-button mouse pretty much cured my partner's carpal tunnel syndrome, caused by several years of Windows use - despite the fact that she works on the computer at least twice the hours she used to. This is simply because one does not have to in any way twist one's fingers and locate a particular button.

OS X is going to make things a lot slower. I have two copies of my VW 9: one that runs under Classic, for actual work, and another that runs under OS X, for mainly generating PDFs with Jaws PDF Creator. Even simple things, like saying 'Select all', are painfully slow in OS X and you definitely don't want to have any imported images in your files.

GraphicConverter and/or CADintosh (both by Lemke Software http://www.lemkesoft.de/) might also work, if one is using a Mac. CADintosh should be able to convert HP-GL to DXF. However (AFAK), PLT does not necessarily mean a particular file type, ie. HP-GL.

Seena, All VW-specific objects (walls, floors, roofs, parametric objects) will be converted to generic 3D objects. You can easily see what happens by exporting as DWG and importing back.

Ceterum censeo, it is about time to make database reports editable - id est,to have a two-way link between any user-editable fields (data records and PIO input) and the listing in a report. I make do with named objects and scripted reports (a normal line for each entry) & returning data, but a normal user cannot be excpeted to do it this way (and I hate writing scripts for the purpose.) Surely, it can't be that difficult - GIS progams such as MapInfo have been able to do it for decades (called exempli gratia 'browse table.)' Right - there is no persistent internal object ID in VW? Well, introduce the concept. At least I surely could use this every so often in my scripts. Sat sapienti.

quote: Originally posted by propstuff: Using classes to name colours sounds like way too much confusion to me. I'd like to amplify this by reminding that there are only 256 colours to work with and that importing a colour palette will inevitably & always throw the previously defined colour scheme out of whack by approximating the old colours to the new scheme. With all due respect, the approximations must be done with an improbability engine.

We do, but it easily leads to otherwise illogical classification of objects and/or proliferation of classes to an unmanageable number; well, at least with our rather complex colour schemes it does. This would be avoided if gradients could be used in 3D. The user interface could be either incorporated in or based on textures. With VectorScript it is possible to define accurate gradients without gradation, ie. solid colours in 24-bit colour space.

quote: Originally posted by propstuff:Oh, and I still want better colour management in VW. :-) It is an absolute shame that gradients can't be used in 3D. IMHO, named colours would be so much easier to use. [ 09-26-2004, 06:23 PM: Message edited by: Petri ]

quote: Originally posted by propstuff: Manual was telling me fibs? He's from Barcelona, he knows noothin. VW 9 Manuel does (page 60) say "Click Import to use a color palette from another drawing or program." Fixed in VW 11 Manuel, it seems. Dunno about VW 10. [ 09-26-2004, 02:00 AM: Message edited by: Petri ]

Well, Eric - now you are talking! We wanted croppable layer links, to be able to do a variety of things from drafting to presentation - but instead got viewports that are only good for printing. Very good, it seems, but they do nothing in terms of making the design process easier and more efficient. WE WAS ROBB'D!