MullinRJ

@leisure, I am not sure why vs.DT_AssociateWithObj() is not recognized as it is working on my machine, but there is a problem earlier in your script. vs.RectangleN() does not return a handle. You must get its handle by using vs.LNewObj(). vs.RectangleN ( origin[0], origin[1], direction[0], direction[1], width, height ) rec = vs.LNewObj() After you make the above change, if you still get an error with vs.DT_AssociateWithObj() not being recognized, please write back. Raymond

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

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 😉

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.

@Sloader, What happens if you escape the "\" character with "\\" so the substring "\\NNR" is interpreted as "\NNR"? I have not tested this, but I've been able to get around things like this in the past. Raymond

Hey @Pat Stanford, Good tip, but while we're on the topics of de-obfuscation and typing conservation, why not elevate the coding experience by declaring a constant to represent a single quote? Particularly in larger scripts, containing multiple formatted strings, I like to use Pascal Constants to represent Tabs, CarriageReturns, and in this case, SingleQuotes. It helps with readability, and faster typing, ... and it's self documenting. At the beginning of any script define the character constants as needed. This is a short list of my favorites followed by the formatting example: PROCEDURE SelectViewport; CONST Tb = chr(9); { TAB character } CR = chr(13); { Carriage Return character } SQ = chr(39); { Single Quote character } VAR ... BEGIN ... MyCriteria := Concat('(L=', SQ, MyLayer, SQ, ') & (T=Viewport)'); Raymond

Hello @RvG, You are close. Your variable MyCriteria is missing two single quotation marks around the Layer Name. The final criteria string should look something like: (L='the Active SheetLayer Name') & (T=Viewport). Here's the Pascal syntax to achieve this. (I took the liberty of removing unneeded parentheses.) : MyCriteria := Concat('(L=''', MyLayer, ''') & (T=Viewport)'); Note, to get a single quote to display in a Pascal String, you need to use two single quotes in a row to represent one literal single quote. So, between the commas in the Concat() statement, the first and last single quotes are string delimiters, and all the single quotes between them should be doubled up (i.e., pairs of single quotes); each pair representing one literal single quote that is part of the string text. It takes some getting used to when you look at it the first time, or the second or third, but eventually it starts to make sense. Python handles this better with two sets of string delimiters to choose from. Another note: Did you notice the & character does not show up in the AlrtDialog() output? It's really in your criteria string, but there be "forces" in the AlrtDialog() call that suppress it. (Ask if you'd like to know the minutiae of WHY.) If you had used Message() instead of AlrtDialog() you would have seen the & character. HTH, Raymond

A few versions ago I had trouble with existing scripts not working on the MAC when I used the backslash "\" delimiter in my $INCLUDE paths. They used to work on both the PC and the MAC. To solve the problem I switched the MAC pathnames to use the colon ":" delimiter. I'm still using colons on the MAC, and like Sam, I use absolute paths. I'm not sure how all of this plays into using relative paths. When I do use a Workgroup folder, colons still work — again, with absolute paths. Now here's the confusing part (at least for me.) After reading the posts above, I went back to a MAC script with lots of $INCLUDE files and replaced all the colon delimiters with forward slashes "/" — it worked. I then tried the backslash "\" — it worked. This is in VW 2022, so my take on this issue is I have no idea what is supposed to be used and what is to be avoided. It seems I can again use any of the three delimiters on the MAC. I haven't tried changing anything for scripts on the PC, but that environment still works with the backslash, and has for as long as I have used it, even when the $INCLUDEd files reside on the MAC, so I'm not about to mess with a working object there. For me, the beauty of using the backslash for a delimiter was that the same code could be used on the MAC and PC, except for specifying the Volume. After that, the paths were identical. Well, at least things are changing back to being more flexible. Raymond

Pat, is it too inelegant to place the WS name into a pre-defined cell and query that when your script runs? Raymond

Hey Pat, Not for nuthin', ActSSheet() still returns a handle to the open Worksheet. I don't know how long it will remain active as it was deprecated in VW 9.0, but it still compiles in VW 2022. You can test with: Message(GetName(ActSSheet)); Raymond

Hi @shiori, I just tried setting the fill color of a rectangle to 50, 0, 200 using your new script snippet and I get the expected result. When I open the color palette to show Active Document Colors, the last color is the newly created color, and as you can see from the screen shot it is correct. This is using VW 2020 SP6. I also tried it in VW 2022 SP4 and it also works. I think you are seeing a bug with the RGB Color Picker. It does not report correct values. I see you are on a PC. I am using a MAC, and I see a similar distortion in the RGB numbers when I look at the RGB slider values, and the Spectrum displays. When you select an object, open the color picker in the Attributes Palette and select the Active Document button (it's the top button at the bottom of the color window). One of the colors will be highlighted which corresponds to your selected object. Hover your cursor over that color swatch and the color values should popup in about a second. Use these values to determine your color. HTH, Raymond PS - I believe this bug has been reported. If not I'll enter one tomorrow.

Try Num2StrF(); It will format your number to the current document units format. If your document units are not in Ft-In, you will have to set the document units to Feet-Inches temporarily before making the conversion, then set it back when done. If you need help changing document units, please write back. Raymond

Good luck with your wish. Raymond

Hi, @Kevin Allen. Reshaper can report the original dimensions and orientation of a solid, even if it is incorporated in another solid, but you have to enter the outer solid container to query the solid inside. Reshaper will work inside container objects, but it won't do so from the outside of the container. That would be cool if it could, but I'm not that good of a programmer. Raymond

Hi Bruce, Relative to what? Forgive me, but I think you are missing the bigger picture. In your specific case, I know what you want, but to get that you have to perform your operations in an orientation that provides your expected answer. This expectation does not hold for every user. Here's a proposal; can you define an exact procedural definition of how VW should report values after solid operations? This has to include situations where there are several solids arrayed in a complex assembly of additions and subtractions. In your case you only have one extrude being subtracted from, what if you had two extrudes of different sizes added together at 90° to each other, then you drill a hole through both at once? Would you expect VW to report the initial unrotated dimensions of one of those extrudes after the composite subtraction? If so, which one? Do you see how this can get very complicated very fast? I appreciate the simplicity you are looking for, but I think it only applies to a very small subset of solid operations, and not the general picture. Respectfully, Raymond

@Bruce Kieffer, Actually, I think the system works as it should. If you were to get your wish, then people who wanted the orientation and size of a solid to be just the way it was when it was created would get false values because VW would have to make assumptions about what orientation the user "should" see. This is a gray area for computer software. In your situation it seems clear, but your reasoning does not fit the general application of creating solids. Your solution of unrotating the extrude before subtraction is a good approach. You know what your dimensions will be when it is done, and it preserves your continued workflow. That said, it would be possible to write a script that would take two objects before subtraction, group them, anti-rotate the group by the rotation of one of the pieces (preferably the object to be subtracted from), subtract, then re-rotate the group and ungroup the result. It's a bit messy, but it would automate what you are currently doing. I think you will be more successful approaching your wish that way, than waiting for VW to address it. Raymond

@Kevin Allen, Reshaper does not do solid subtractions, rather it can be used to edit a solid after a subtraction is done, or edit the parts inside the solid. I just performed two subtractions from a 20" x 20" x 3/4" extruded rectangle (slab). The first was was done when the slab was unrotated and the hole was perpendicular to the slab. There was no change in slab dimensions after the subtraction. I then rotated the slab 30° around the Y axis and subtracted another hole from it. The hole was unrotated from its extrusion plane, and it drilled a hole at 30° through the slab. Reshaper and the OIP both show the resulting solid subtraction with different dimensions from the slab's original values, but the slab's original dimensions did not change. It appears VW is looking at the final solid subtraction as an unrotated solid and reports a new Bounding Box accordingly. The slab inside the subtraction is still rotated and its initial dimensions do not change. I measured all three slab edges on the outside of the subtraction and came up with 20 x 20 x 3/4. Even Bruce's last picture shows the expected slab values. Reshaper and the OIP show the new solid as rotated 0°X, 0°Y, 0°Z , and 17.695" Width x 20" Depth x 10.65" Height; so the reported values are deceptive when compared to the original slab values, but they are correct. The internal components of the Solid Subtraction are intact. Entering the solid, Reshaper shows the slab still as 20x20x3/4" and rotated 30° around the Y axis, just like the starting slab's values. I don't think there is a solution other than the one @Bruce Kieffer originally employed, by unrotating the slab, doing the subtraction orthogonal to the VW axes, and re-rotating it when done. It's what I have always done. When solids are created, their unrotated (0,0,0) orientation is defined relative to VW's XYZ axes at the time of creation. Not sure if this helps, Raymond

Well, this was obviously wasted effort... XXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXX

@Sam Jones, The only place I see that record existing is in the "Spotlight (UK Metric).sta" stationary file. The other two stationary files supplied by VWInc, "Spotlight (Metric).sta", and "Spotlight (Imperial).sta", don't have it. You'll have to import it or recreate it. I only searched VW 2022 supplied files. Raymond

Hey @Sam Jones, Checkout GetVPGroup (viewportHandle : HANDLE; groupType : INTEGER) : HANDLE ; groupType values: Crop = 1 Annotation = 2 Cache = 3 It should do what you want, assuming you're outside the viewport looking in. As to DataVisualizations? I dunno. Raymond

@LarryO, To the best of my knowledge, there is no implementation of 3D Control Points in Plug-Ins. I have heard many requests for them in the past. Assuming you could even see a CP in a Front or Side view you would be looking at it edge-on on its working plane. Grabbing a CP in a 3D view would not allow you to move it in the Z-Direction. I don't have an example to test here, so I'm speaking from faded memory. Sorry, this is not what you wanted to hear. I think the only exception to the rule would be a 2D Plug-in placed on a 3D Working Plane. The CP would be visible in 3D views, but it would still be limited to only moving in the Working Plane. Raymond

Hey Pat, On some compilers there may be, but I don't think VS is one of them. But I'm guessing, so please don't take my word for it. Ask someone who knows. As it applies to runtime issues, I doubt a user would ever see a difference. You would have to be processing hundreds of thousands of objects until a statement like True=True would become noticeable. I have a hard time putting 30K+ 2D objects on one layer. VS can run through them quickly enough, but redraw becomes the crippling issue. Most scripts will probably never get loaded that heavily. Actually, I have been amazed more than once at how fast VS will run through 100,000 objects, or even 1,000,000 – like counting them, or changing a single attribute. In many areas Python and VS are on fairly even ground, but in some things Python can seriously outperform VS. This could be the seed for an entirely new Geek-Out thread. Raymond

Hi, @MarcelP102, Well done. Just a thought. Though it may be easier to read, it is not necessary to compare a boolean function to a boolean value. More simply said, Selected(H2)=true is the same as Selected(H2). It is akin to writing the expression If (True=True) then {do something}, which could simply be written If True then {do something}. Likewise, in <criteria> statements people very often write (SEL=True) when they could simply write SEL. The only advantage I can see is that for people who don't program much, writing (SEL=True), or (Selected(H2)=true), it maybe easier to follow the program's logic. It's not wrong, it's just redundant. HTH, Raymond

After you get a handle inside the wall, with FIn3D, loop through all objects in the wall and test each object for being Selected, and either a Symbol, or a PIO. Use GetTypeN(H) for the type. I use a while loop, but you can use ForEachObjectInList(), too. Quit when Found is true. where H is a handle of an object inside a wall... SymType = 15; { Symbol Instance type } PIOType = 86; { PIO type } Found := Selected(H) & ((ObjTyp = SymType) | (ObjTyp = PIOType)); { selected Symbol | PIO } Raymond

Hi @matteoluigi, One letter off and the whole thing comes tumbling down. It took me several minutes to spot it, so don't feel too bad. You are getting the length of the LIST "prefix" (always 3), and not the VARIABLE "aprefix". Change this: if (aClassName[0:len(prefix)] == aprefix): # prefix is a List of length 3 To this: if (aClassName[0:len(aprefix)] == aprefix): # aprefix is an element of List prefix and you are good to go. All else looks good. Raymond