Font size in BoxText()

[snowsnowsnow]

I'm pretty sure I knew how to do this once, long ago, but I can't remember any of it now.

I have a simple script that uses BoxText() to display text in the default box.  Nothing fancy, no dialogs, no tricky Box stuff.

But the text is pretty small and hard to read from across the room.

How do I make it bigger?

[td]

See the BoxTextFont function.

[snowsnowsnow]

The good news: My versions of WinBatch recognizes BoxTextFont() as a valid function.

The bad news: I have no idea how to use it - what parameters it needs.

One thing that has annoyed me for as long as I've been using WB is the fact that the Boxes functions aren't considered to be part of the main language (WIL).  They are somehow relegated to "the little green book" - and I always had to find that green book whenever I needed to use them.  Having moved a few times since I last had a copy of the little green book, I have no idea where it is.

In particular, I just looked now at the machine-readable help file and could not find any docu on the Boxes functions.  The only reference to BoxTextFont() is in the example code for ArrDimension(), where it shows BoxTextFont() being called with about a half dozen parameters, the first of which is the number 1.

This last point - the number 1 as the first parameter - makes me think that it is connected with (what I call) the complicated Boxes functions, not the simple ones.  The complicated ones all take a first param which tells it which set of Boxes to work with.

In any case, can you give me a simple usage of BoxTextFont()?  Will it work with the simple BoxText() function?

[td]

The "box" function are not a part of WIL.  That means that other products that use the WIL interpreter DLL do not have access to them.  "Box" functions are implemented in the WinBatch executable itself.

The "box" functions are fully documented in the Consolidate WIL Help file.  If your old version of WinBatch does not have the Consolidated WIL Help file, they should be documented in a separate WinBatch.chm file in the main WinBatch install directory.

[td]

Unless your version is so old that you don't have ".chm" help files.  In that is the case, the "box" functions would be documented in the "WinBatch.hlp" file.

[snowsnowsnow]

Yeah, OK.  I have WinBatch.hlp file.  Thanks for pointing that out.

I got the example for BoxTextFont() working.  I should be able to figure it out from there.

But, just in the "for what it is worth" category, it looks like you do have to switch over to the "complicated" Box functions (the ones that require you to use BoxesUp() and to pass the index (the number 1) to every function) in order to use BoxTextFont().

I still have this vague memory of there being a way to do it while staying within the confines of the "simple" Box functions.  Maybe I'm imagining things.  But maybe not...

[td]

If I remember correctly, you can just use box id 0 to change the font in the default box.  That should simplify things a little, if it works.

[snowsnowsnow]

0 doesn't work.  You get a fatal error - something about an invalid index and it says it is an Extender Error (even though no actual Extender is involved).

However, using 1 does seem to work - seems to be an alias for the default box.

I haven't tested this thoroughly, but it does seem to work like that.

So, it looks like my problem is solved.

[td]

Chalk one up to early senility.  You are correct. The default box is 1 and not 0.  Internally, the box ids are zero-based but are one-based from the user perspective.

The reason the error mentioned something about an extender is that from the WIL DLL's perspective any error caused by an event that occurred in code not implemented in the DLL is in an extension of WILL, e.g., extender.  In other words, the term extender has a more general meaning than a DLL loaded into memory.

[snowsnowsnow]

Yep, that makes sense.

BTW, one more thing I noticed.  After running for awhile (a few hours), my script, which updates the box every 60 seconds), aborted with an error message about the Box Stack being full (or something like that).  I remembered this from having hit this problem before, and fixed it by doing:

BoxDataTag(1,"Tag1")

just before the main loop, and then putting:

BoxDataClear(1,"Tag1")

inside the loop - i.e., as the last statement in the loop.

But the thing is, I am unclear as to when you need this.  It seems to be necessary if and only if you do anything that involves passing the parameter (the "1" as the first argument to a Box*() function).  Is this correct?  Or, would the same problem have (eventually) presented itself even if I only use simple BoxText()?

I'm pretty sure that the earlier version of this program (before I decided to ask here about how to make the font bigger) did run for at least 12 hours (before I killed it to run a new version).

[td]

There is a "new" box implementation and an "old" box implementation in the WinBatch executable.  When you start using box functions that require a box id, you are using the "new" box implementation.  The "new" box implementation maintains a database of box commands to use the next time the box is drawn.  That database cannot contain more than 150 box commands.  I don't know how much is documented in your old help file so here is a quote from the current help file:

"...In a normal Windows application, the application must be ready to redraw all or any portion of its window at any time. This adds considerable complexity to a true Windows program. In WinBatch, the programmer is shielded from the gory details of the dynamic redrawing required by Windows, and maintains the simple, traditional linear programming style.

In order to do this, WinBatch maintains a small database of the Box commands requested by the programmer, and refers to this database when Windows requests a redraw. In general, and for simpler applications, the existence of this database is completely transparent to the programmer. There are cases, however, in which the database must be managed by the programmer to avoid reaching the maximum limits of the database. If the maximum limits are reached, the program will die with a Box Stack exceeded error.

If there are some objects that constantly change, such that the limit of about 150 Box commands in the stack will be exceeded, then you must manage the Box Data. The idea is to draw all the fixed, non-changing objects first, and then place a "TAG" into the Data stack, using BoxDataTag. Then draw the first version of the constantly changing object(s). When it comes time to update those objects, a BoxDataClear will erase all items added since the (BoxDataTag) "TAG", and all remaining data space will again be available for reuse.

The thermometer bar and the text for the note in the setup program use this feature. All of the examples that do continuous screen draws also use these functions"

[snowsnowsnow]

OK, yeah, that all makes sense.  I think I've read that (or close to it) already (in my [old] version of the documentation).

But thanks for clarifying that there are two "box" implementations and that, as I've suspected throughout, once you use anything that requires an index, then you are in the land of the "new" implementation.

And, thus, have to worry about BoxDataTag() and BoxDataClear().

Bottom line: It would be nice if there was a way to change the font without stepping into the Brave New World, but it seems there isn't.