Martin Tye

Pat - thanks - yes, in fact, that is exactly right (per Josh's previous post). The difficulty I was having was to figure out the names each record and field but, for anyone else who is wondering, the record names are as follows: recname:='Title Block Project Data'; recname:='Title Block Sheet Data'; etc. Once the record name is identified, the field names are exactly per the list - eg. "Project Name" I haven't got as far as looking at the revision numbers or some of the other features yet.... BTW - to use Get / Set RfField, a handle is required to the relevant object. In this case, the object is the title block. The way I was (and still am) getting the handle was via h1:= GetObject('Border'); having named the title block 'Border'. Is that the most efficient way to get a handle to it, I wonder or is there a better way to select the object, directly? (It is an '86' ie. PIO). It would be great to have your thoughts on this.

Hi I wonder if there might be some more concrete examples of how to populate the new title block fields via vectorscript - I'm struggling to make much sense of it. Does anyone have any useful info on this please?

I don't see anything on any of the forums about scripting with the new title blocks? Previously, it was possible to pass information to title block records, that would then appear in the title block, via vectorscript but does anyone know if there is any guidance available about how to achieve this in VW 2018 please?

Thanks Matt. If ok with you, could I send you two vwx files - one as 2017 and one as 2018 - by email? May I have your email address please? (It will be a day or so for me to send).

Actually, it was rendered in Hidden Line. I don't know much about this (as you can probably tell!) but what was good about the Shaded Poly rendering that I had been using (from around VW 2015) is that it seems to have been much simpler and quicker, by comparison - and 'cleaner' (fewer lines and no fuzzy shading). There does seem to be a lot of 'noise' now in the Viewport view of the object (hidden lines and points) that show up in the Final Shaded Poly version but are NOT there in the actual 3D object itself. It's all a bit weird.

Many thanks, Josh - that does seem to do it! I since, found that Final Shaded Polygon also seems to get around the problem but I take your point about it being a legacy feature so will try to avoid using this. In both cases, it seems as though the rendering is slower than it was previously and it is odd (to me) that these settings are having to be changed, moving from VW 2017 to 2018. One other point is that, set up as you have suggested, the line where the back upstand meets the worktop should be obscured by the side upstand but it remains visible in the Viewport. It all looks rather clumsy in the attached screenshot but I think you can see what I mean.

Many thanks, Matt. Doing those things does not seem to help but whilst looking at these settings, I have noticed that the viewport displays correctly when Background Render is set to Final Shaded Polygon. I suspect that this does take a lot longer to update though...

I did post this in another area of the Community (Architecture) so apologies if this is doubling it up but I wonder if anyone can shed any light on this please? The 3D solid object is absolutely correct (does not appear to contain any errors) when viewed on its own Design Layer (in OpenGL): But when viewed in a Viewport from a Sheet Layer, it looks like this (as a Shaded Polygon): It's a bit of a long story as to how the object is produced (I can provide details if required) but it is a 3D solid object, derived from various solid additions and subtractions. This has just started happening with VW 2018. Does anyone have ideas as to what could be causing this please?

Thanks Christiaan - I had been using Shaded Polygon as the Background Render mode in the Viewport - and OpenGL for the object itself, on the Design Layer. I found the setting you mentioned and increased it to 70˚ but this seems to affect the viewport output only when the viewport render mode is set to OpenGL (but this looks rather imprecise and fuzzy, compared to the results I was getting with Shaded Polygon). As ever, there are way more settings than I even know about! Just as an example, I am attaching a Viewport screenshot, using VW 2017 and I wonder if this provides more of a clue as to what might be happening?

I wonder if anyone can shed any light on this please? The 3D solid object is absolutely correct (does not appear to contain any errors) when viewed on its own Design Layer: But when viewed in a Viewport from a Sheet Layer, it looks like this: It's a bit of a long story as to how the object is produced (I can provide details if required). This has just started happening with VW 2018. Any ideas please?

Thanks Both!

Glad you like it - I forget how I arrived at it but is great to find ways to achieve goals that, sometimes, seem unachievable. Let me know if you need any help with it but I think you should have enough info to get it working the way you want it to.

Hi Raymond Many thanks for your most full and complete post - which is exactly what was happening. I have now reset the saved settings (and then selected always Yes) and this is all working fine now. I think you saw this from Pat's post that I had set up as a new subject. Thanks both for super-quick and ultra precise help and analysis!!!

Pat That is brilliant - thanks so much. I was thinking it had to be that setting but I just could not find how to get to it! It was a bit of a slog but, with that now answered, I THINK I have managed to get all of my tools working within VW 2018.

It seems that Ungroup (either invoked via script or manually) now prevents any attached records from transferring to the constituents parts of the group. Is this a change or am I missing something here (eg. it is a preference setting)? Any help would be much appreciated.

After a lot of effort trying to trace exactly where the problem(s) were, it seems to have come down to poor choice of variable names, per Raymond's initial response. (The concat criteria were not necessary to make the script run, though may be a better / more robust method for selection). SP1 certainly seems to have helped to resolve some of the issues. I now have noticed another issue - it seems that when Ungroup is used, any record data pertaining to the group is no longer transfered to the ungrouped items, as it did previously. I'm not sure if this is a setting or a change in the way the program works - I may create a new post for this, in case it is not very visible within this string - but has anyone noticed this or can shed any light on it please?

That is very interesting to hear. I hope this could include a solution to some of the problems I am experiencing - I have spent the last few days trying to isolate why some scripts have just stopped working (in VW 2018). They compiled fine but just did not work as they used to. I will now 'down tools' until this new release becomes available...

Hi AE, I created a script to do this, using the Pos and Copy functions with these variables: pioName,letters,letter,remainl,nextl, new: STRING; loc: INTEGER; and based on the code below and by running the 'nextLetter' from your main program block. It works very robustly but it did take a bit of fiddling around with to set it up.... What it won't do is allow you to enter your own letter / label to the new item. PROCEDURE removeLetter (h2: HANDLE); BEGIN pioName:=GetPioName(h2); letter:= GetRField(h2,pioName,'Ref'); loc:=Pos(letter,remainl); IF loc <> 0 THEN BEGIN Delete(remainl,loc,1); END; END; PROCEDURE nextLetter; BEGIN letters:= 'abcdefghijklmnopqrstuvwxyz'; remainl:= Copy(letters,1,26); ForEachObject(removeLetter,((C='XXX') AND (T=86) AND (V=TRUE))); IF COUNT ((C='XXX') AND (T=86) AND (V=TRUE)) = 0 THEN BEGIN nextl:='a'; END ELSE BEGIN nextl:= Copy(remainl,1,1); END; END; It is not very obvious but I hope this could be helpful to you and good luck! MT

And there speaks the voice of experience x 3, to the power of three! Thank you so much for those insights - I shall be taking lessons and elements from all three Masters: • I had since figured out the chr(39) usage from one of Pat's recent posts and I do prefer this over the multiple quote marks, that certainly do get confusing. • I have switched to JB's concat criteria which are working nicely. • I shall be avoiding the use of vs reserved words, per RM's suggestion (but I need to repeat the procedure for various variables so [I think] I need those lines to enable this). Gents, thank you again. I will put these into practice and see how things look then but here do seem to be some other things happening, since working in the 2018 environment (on Mac). Obviously, these are irritating but, perhaps provide a 'test' and a way of improving / refining the coding over time. Whilst on, this is actually my first ever post on this forum but, having had to learn vs 'the hard way', as a non programmer, I found the forum totally invaluable and there is no way I would have been able to develop the tools that I have needed to, without it. I have literally trawled it for information and solutions. It is an amazing resource and I owe a big thanks to all of its key contributors!

Hi, Here is a snippet from a script I have been using for some time but, with the advent of VW2018 it has stopped working. It seems that the variable string 'sides' is no longer passed to the Class type selector in SelectObj (it only works if the actual selector is set to (C= 'sides') directly). Procedure CustTool; VAR LineType:STRING; PROCEDURE Poly (line: STRING); BEGIN lineType:= line; SelectObj((C=lineType) AND (V=TRUE)); END; BEGIN Poly('sides'); END; Run(CustTool); Has anyone else come across this /can anybody shed any light on it please?