Jump to content

Martin Tye

Member
  • Posts

    20
  • Joined

  • Last visited

Posts posted by Martin Tye

  1. 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.

     

     

  2. 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. 

  3. 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.

     

     59ef45b800057_ScreenShot2017-10-24at14_40_01.png.7d4abde9fe8cd57d02d1f0e3b3725d9b.png

  4. 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):

    59edfe90df72f_ScreenShot2017-10-23at15_28_08.png.d33e8ab80b75aa4d3b8019e0741ddb91.png

    But when viewed in a Viewport from a Sheet Layer, it looks like this (as a Shaded Polygon):

     

    59edfed3ebdc1_ScreenShot2017-10-23at15_29_28.png.2ce499d7475cc228c5e10b1689e4981d.png

     

    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?

     

     

  5. 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?

     

    59ee09c6bce17_ScreenShot2017-10-23at16_23_14.png.806ac6aaa33bed4950cc2046395af882.png

     

  6. 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:

    59edfe90df72f_ScreenShot2017-10-23at15_28_08.png.d33e8ab80b75aa4d3b8019e0741ddb91.png

    But when viewed in a Viewport from a Sheet Layer, it looks like this:

     

    59edfed3ebdc1_ScreenShot2017-10-23at15_29_28.png.2ce499d7475cc228c5e10b1689e4981d.png

     

    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?

     

     

  7. 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?

  8. 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

  9. 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!

     

     

  10. 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? :|

×
×
  • Create New...