topic Re: Marker: Reveal Depth GLOBAL/Request in Libraries & objects

Marker: Reveal Depth GLOBAL/Request

owen — Wed, 24 May 2023 10:07:28 GMT

Is there a Global Variable or Request available within a marker subtype to get the depth of the reveal?

I've tried:

WIDO_SILL
AC_WIDO_SILL
WIDO_THRES_DEPTH
AC_WIDO_THRES_DEPTH

I've also had a look at some of the W/D markers in the AC library and unless i've missed something (likely) none of them seem to read the reveal depth from the door/window settings

Re: Marker: Reveal Depth GLOBAL/Request

Frank Beister — Fri, 18 Aug 2006 09:53:24 GMT

So far I can see, you will not get this information out of a window marker. In absence of the window GLOBALs in the marker environment you have only access to the blue optinal Parameters, which are feed by the calling window.

Bad workaround:
Modify your windows by an parameter as "IcontainWidoSill" and the line

parameters IcontainWidoSill=WIDO_SILL

in the first line of the master script.

The marker could request this storage of the sill depth inside the window objects by sts=REQUEST ("ASSOCLP_PARVALUE",...
See other threads to this command for the right syntax here.

Not shure this really works, but it's an idea. (REQUEST ("ASSOCLP_PARVALUE","WIDO_SILL"...) can and does not work. I have just ried it. 😉 )

Re: Marker: Reveal Depth GLOBAL/Request

owen — Fri, 18 Aug 2006 13:37:20 GMT

Yeah I tried using REQUEST(ASSOCLP_PARVALUE...) and none of them work on Globals available to the window/door

This is very frustrating ... IMO all the globals available to an opening should be available to associated markers/labels (as AC_Global...). There are many which are available, but I have only found these by trial and error as most of them were not automatically created when i picked the marker subtype. I would have thought the depth of the reveal/sill in particular was a pretty obvious thing to want to access in a dimension marker Most of the markers i've seen even have a parameter for this, but it has to be edited by the user rather than reading from the opening

I will try the workaround you suggest using REQUEST(ASSOCLP_PARVALUE...) to get another var=WIDO_SILL from the door which will work, but as I am trying to create a marker which will work with any of the AC10 Library doors i will have to wade through their scripts and see what they have used for this variable, rather than add one of my own. Not looking forward to it - their macro calls make my head hurt. Hopefully it is consistent across their doors and so will not be too complicated (they do at least use consistent parameter names from what i've seen so far).

Re: Marker: Reveal Depth GLOBAL/Request

Frank Beister — Fri, 18 Aug 2006 21:31:14 GMT

IMO all the globals available to an opening should be available to associated markers/labels (as AC_Global...).

IMHO too.

There are many which are available, but I have only found these by trial and error as most of them were not automatically created when i picked the marker subtype.

Which one have you found beside real globals and the blue optional one? Sounds like undocumented knowledge. 😉

Re: Marker: Reveal Depth GLOBAL/Request

owen — Sat, 19 Aug 2006 02:42:13 GMT

F. wrote:
There are many which are available, but I have only found these by trial and error as most of them were not automatically created when i picked the marker subtype.
Which one have you found beside real globals and the blue optional one? Sounds like undocumented knowledge. 😉

I wish! No i'm just refering to the fact that there are many more of the blue optional ones available for the marker subtype than are created by the subtype. I don't know if they are hidden away in some documentation (like the HTMLs) but i found them either by opening other GS markers or by trial-and-error (adding AC_ to the front of some global variables used by doors/windows).

ALL the available blue optionals should be automatically created by the subtype ... we don't have to use them but its better than wasting time finding out what is available.

Re: Marker: Reveal Depth GLOBAL/Request

Frank Beister — Sat, 19 Aug 2006 11:03:46 GMT

No i'm just refering to the fact that there are many more of the blue optional ones

But where do you know from, that it's a fact? Which one have you found?
There are some new (AC10) optional ones, which are not created automatically, when you choose the certain subtype, but these are documented in the Basic library documentation.

In opposite to the gloabal parameters, I haven't found the complete supported list of optional parameters in the AC resource files. I guess there is no one.

Re: Marker: Reveal Depth GLOBAL/Request

owen — Mon, 21 Aug 2006 04:46:13 GMT

F. wrote:
There are some new (AC10) optional ones, which are not created automatically, when you choose the certain subtype, but these are documented in the Basic library documentation.

Yes those are the ones - i hadn't found the Appendix A - Fixed name optional parameters in the Library Developer docs yet .. do now. Handy stuff to know

When creating a new Window-Door Marker the only optionals created by the subtype are:

AC_WIDO_ID
AC_WIDO_A_SIZE
AC_WIDO_B_SIZE
AC_WIDO_REVEAL_SIDE
AC_WALL_THICKNESS

only 5 of the 38 of the available ones - and none of the 38 give you the reveal depth. That has to be an oversight surely. Oh well at least they give you predefined font, pen & size parameters for 4 different text styles to compensate.

Re: Marker: Reveal Depth GLOBAL/Request

owen — Mon, 21 Aug 2006 07:43:32 GMT

OK i'm stumped.

Had another look at this this afternoon and I can't find where the hell in the mess of f-ing macro calls that make up GS doors there is a parameter for the Reveal depth accessible via a REQUEST("ASSOCLP_PARVALUE"..). I can easily find all the parameters for frame dimensions (thickness, width, rebates etc) and door leaf dimensions.

There were a few parameters i found located in macro calls (like Door Functions.gsm and DoorThresholdTrim.gsm)that are created based on the globals WIDO_SILL or WIDO_FRAME_THICKNESS but none of them would return a value to the Marker script. I checked this by creating a text string of the return value for REQUEST("ASSOCLP_PARVALUE"..) as part of the label and every time i got 0. I know there was no error in the request script as i successfully used the same line to request parameters like gs_frame_thk from the door, use the parameter in ADD2 and also create a text string of the return value (1) to confirm the request was returning a parameter.

It just shouldn't be this hard to write a simple bloody label ffs! Sick of messing around with this - i'm just going to CALL the damn label directly into the doors 2D script where it will behave with the rest of the door.