I would also suggest adding a bit of free advice:

"It is strongly suggested to gather up all your declarations and place them at the beginning of your
sub or function.  This is to avoid any 'scope' issues."

Or something to similar effect.

cheers, mru

Hello Group,

As somebody using 4-year-old BCX and PellesC, there arises a desire to make modifications to the help file.

Robert is very conscientious about keeping the help file up-to-date, by adding new features and clarifications to existing features.  But it is unwise for me to use the latest help file, it contains features which don't exist in my 4-yr-old version of BCX.

In addition, from time-to-time I stub my toe on BCX, not getting something right because I didn't read it right or because I didn't understand what was written.   When you learn from a book, you may write notes in the margin to enhance or clarify what is written.

I would like to know how to "annotate" the help file so as to be able to add things to watch out for and add things which allow me to better understand what is going on in BCX.   Also to add code snippets in places, so I don't have to go looking for something I already wrote years ago.

cheers, mru

p.s. I do know rudimentary HTML, even DHTML.

A test case may be found in "bcxPrint_moRpt.zip", located here:

https://bcxbasiccoders.com/smf/index.php?action=dlattach;topic=1038.0;attach=1307

Go to the include file named: Print_IFPS_Report.bas.

Change the declaration on line 229 from Global to Local.

Then you should get an error pointing to line 249, saying that "inLeftSp" was not declared,
  -- at least I did.

cheers, mru

p.s. If "Morgan" is correct, then the help file should be changed.  Local only applies to "scope"
which may be just a "segment" of an if statement -- not the subroutine.

Hello Group,

This question was prompted by the following code:


Local inPgWd as Single : inPgWd = 8.5 - oPrn.RightMargin - oPrn.LeftMargin  ' assume 8.5 x 11
Local inFreeSp as Single : inFreeSp = inPgWd - inWidth  ' wd of text
Local inLeftSp as Single : inLeftSp = (inFreeSp / 2) - 0.2  ' fudge (local not working)

      oPrn.Text_Out(&oPrn, inLeftSp + oPrn.inCurX, oPrn.inCurY, TRIM$(sOutLine$))

      oPrn.Set_Font(&oPrn, hMonoSpFont)  ' set normal font


    ' testing for underline (header only)...
    ELSEIF (INSTR(sOutLine$, "----------")) then  ' underline, so draw a line

       ' use the left-hand fudge factor previously declared...
       oPrn.Draw_Line(&oPrn, (inLeftSp+oPrn.inCurX)-0.25, oPrn.inCurY + 0.2, inWidth + 0.5, 4, crBlack)

    ' Check for section title...
    ELSEIF (INSTR(sOutLine$, "EQUITIES") _


PellesC (v6.5) throws an error, the second instance of "inLeftSp" is not defined (the draw_line stmt).  So I changed the Local to Global and went on, BUT...

Why the error?  The help file says that a Local declaration should be good for the entire subroutine.  In this case, it was only good for the one segment of an extended "if" statement.

Granted, I am using a four-year-old version of BCX and PellesC, but I'm not aware of the Local declaration changing that much in those four years.

You may be disparaging me for practicing "declarations-on-the-fly" (i.e., putting in a declaration whenever a new variable is introduced), rather than the more common practice of sweeping up the declarations and placing them all first in the subroutine.

If that's the answer, then the help file should say that.

cheers, mru

This printer class code is nothing more than a basic-like interface to the system printer api.  I find it more convenient than rewriting the apis each time I want to do some printing.  You C++ fans may be disappointed that this is not a "real" class, rather it is a typedef-based "C" class as found in the BCX help file.  As long as you can tolerate adding a class reference to your sub+function calls it is easy enough to use.

Of course there are some full-featured printing capabilities built into msWord and msExcel (and libreOffice if you prefer).  However, there are some other situations where a do-it-yourself approach is useful.  I used it to print checks until online bill-pay came along.  (I liked to use a program because I always had trouble spelling forty/fourty and ninty/ninety when writing checks by hand).   I use it to print my IFPS reports.  (IFPS is a financial program with primitive output, see "Spreadsheet Wars" comment below).  There was a time when I was required to fill in a monthly report with the same information every month.  I wrote a program to fill in the info.  I also use it to print envelopes (for example Christmas cards).  Yes, I do realize that msWord has an envelope printing feature, but I found it more complicated that writing my own program.   So, those were my motivations for writing the class code.  It has been worked on over the years, and this is only the current version.  It is never finished.

This code was developed on a win98 (legacy) computer, now running winXP with an Epson LQ-950 dot-matrix printer attached (kindly refrain from disparaging or sarcastic remarks).  It also works on a more modern win10 system (not win11 capable, but linux-ready) with a Brother ink-jet printer.  Your results may vary.

Two demo mini-apps are attached.  One is a program to re-print IFPS output so that it looks more professional.  The second mini-app will print an envelope using xml input.  (It is a drag-and-drop app).

Best Regards, mru
developed on win98+XP, with bcx v7.4.5, and pellesC v6.5.   Runs on win10.



My usual disclaimer: the code could use some polishing and beautification, but works well enough for my purposes. 

"The Great Spreadsheet Wars".  The usual reaction when you see this is to think "msExcel vs Lotus 1-2-3 vs VisiCalc,  However, to me it has another meaning: cell variables vs named variables.  By that I mean spreadsheets oriented around cells identified as letter+number (for example column "A", row "11" is identified as "A11").  There is another way for a spreadsheet to work, i.e., "named variables".  For example, you might write: "Net Profits = Sales - Raw Materials - Overhead".  Or, you might write: "Inc(Dec) = Net Profits[2024] - Net Profits[2023]".  Coming from a past of writing FORTRAN programs, the named variables approach seemed more natural to me.  In the 1980's and 1990's there were a number of products using the "named variables" approach.  Interactive Financial Planning System (IFPS), Lotus(Next) Improv and Javelin to name a few (still sitting on my bookshelf).  Many financial firms and business schools choose the "named variables" products -- based on merit.  Obviously, msExcel won the war (based on market domination?), but I resisted.  I still use IFPS.  It works natively on win98 and winXP, but as a 16-bit app won't work on win10.  Not to worry.  It runs just fine under VDOS.  The output is plain-looking line output.  But I felt compelled to jazz it up a little, using the system api (i.e., this printer class code). 

Anybody curious about the shortcomings of cell-oriented spreadsheet programs might like to read this.  https://en.wikipedia.org/wiki/Spreadsheet#Shortcomings

Kindly refrain from sarcastic remarks about my dot-matrix printer.  Granted it was expensive ($500) and the print quality is a little less than modern standards, nevertheless it has continued to clunk away reliably for the last 30 years, producing legible output, with new ribbons costing about $10/yr.  During that time, at least a dozen ink-jet printers have been consigned to the recycling center, and usually with an abundant amount of annoyance and swearing to accompany their departures.  My printer cartridge drawer is filled with unused replacement cartridges, the sum total of which cost way more than my dot-matrix printer.

For you conscientious cross-checkers, don't bother.  The IFPS rpt is a dummy, and you will find the columns don't add up.  Trust me, IFPS can accurately add up a column in real life.

If you want to try the PrintEnvelope app, it is drag-and-drop.  But if you want to use it on a regular basis, I suggest adding a registry entry which will add the PrintEnvelope app to the context menu for xml (envelope) files.  (The attachment is from winXP, but the win10/11 reg file should be similar).

Back during my scripting days, we had fun controlling other apps.  If they were COM apps, then the COM interface made manipulating them easy.  For apps without the COM interface, one had to result to various tricks (remember AppActivate and Sendkeys?).  I called those tricks my nonCOMAppToolkit.

This came to mind recently.  I use the 7-zip utility to make backups. However, when I switched my legacy system from win98 to winXP, I ran into a problem.  With 7-zip, if a file is in use by another app, then 7-zip will report it and then stop.  I worked around this in win98 by programming in exceptions to 7-zip for "busy" files.  But in winXP, there were too many exceptions.  Instead of walking away and letting the backup routine run itself, I had to stick around and click the "close" button (frequently) to get through the backups. I longed for a routine which would click the "close" button for me.

FULL DISCLOSURE: This is not a rewrite of the nonCOMAppToolkit for BCX, it is only a start.  There isn't very much to it.  It will find the 7Z window and the close button, then click it.

Take One.  I used two enums, one to find the 7Z window, and another to find the button.  7Z uses the same button for "cancel" when it's running, and "close" if it's finished but still displaying exceptions.  Then I had a "wait loop" which would check periodically for the "close" button, if any.  In the wait loop I used the two enums to find the button and check whether its caption was "close".  Kindly hold your screams of disparagement and disrespect.

I know what you're thinking: I didn't really need any enums.  You don't need an enum to get the 7-zip window -- just use GetActiveWindow.  That may work 99pct of the time.  As for the second enum to get the close btn, you could use GetDlgItem.  You can get the ctrl ID programmatically, or manually using windows SPY.  And my poor mono-core PIII had trouble keeping up with all those enums.

Take Two.  This is based on two assumptions.  That the hWnd of the 7Z app won't change while it's running, and the hWnd of the btn control won't either.  Also that 7Z will use the same btn control for "cancel" while running, and "close" when finished.  Reasonable enough.  I used an enum to get he 7Z hWnd, and the ctrl ID to get the button hWnd.  Instead of the "wait loop" I used the timer, which was running to update the clock in the statusbar.  So in the timer handler, I look for the button caption to change to "close" then send a button click msg. 

So now this code will go into my backup app, and I expect that I will be able to start the app and walk away, confident that it will keep going to conclusion.

cheers, mru.
developed on winXP, with BCX v7.5.0, and pellesC v6.5. Works on win10.

My Usual Disclaimer.  I worked on this until it was good enough for my purposes.  It could obviously use some code polishing and beautification.  I may get around to that later, but probably not.

If you try running this, you may need to review the filespecs.  The test starts with a BFF, to ask where you want the zip file to go.  I will be zipping up a folder in windows which is guaranteed to show busy files.  I also built in the default location for the 7-zip program, but in your case you may have installed it elsewhere.  On my own systems, it was installed in different places.  If you do have 7Z installed, there is probably a path to it in the registry.  I checked on that location too.  If that doesn't work, you will have to re-adjust the code. 

Are you wondering why I am using 7-zip instead of the prescribed microsoft backup utility built into windows?  That is another topic. 

P.S.  AppActivate is awkward in this situation, as 7Z is using the titlebar instead of the statusbar to show progress of the zipping (in addition to the progress bar).

Hello Group,

I was wanting to show a second window, and found a handy example for this called the "Two Forms Demo" on the "FUNDCTION and SUB" help file page.

I tried the example code, and it worked perfectly well "as-is".  However, when I tried it in my program, it caused the controls on the main form to become scrambled.  That made me think that there was some sort of confusion between the wndprocs for the two forms/windows.

I then noticed an example on the "BEGIN EVENTS" page, which suggested a notation on the "BEGIN EVENTS" and "END EVENTS" statements which would tie the event loops more closely to their form/window.  That is, adding a form identifier to begin, and adding MAIN to end events (in the main window), and similar treatment for the event loop associated with the second form/window.

That worked for me.  Full Disclosure: I also removed some re-sizing code, so more testing should have been done to determine which change caused the problem to go away.

But anyway, I think it might be worthwhile to modify the "Two Forms Demo" example to reflect the advice found on the "BEGIN EVENTS" page.

cheers, mru

developed on winXP, using BCX v7.45, and PellesC v6.0 
   (sorry, if this was already addressed in some later version)

Thanks for the help and advice.

I will try recompiling bcx with the suggested compiler flags.  There was a case where the previous bcx version could not be used to translate the newer version, and a "special bcx" had to be used, and I assume that special version will be win10 (not winXP) compatible.  So that version will have to be translated over on win10.

My attempt to load win7 on vintage pc was unsuccessful.  Will try Vista.  Vista gets a lot of hate on YouTube.  The Vista supporters say the hate is directed at the new features, which later became the features people loved in win7.

cheers, mru

My vintage win98 system is now running winXP.  It's not quite up to ms requirements, but is running ok on an SSD.

I moved my development utilities (bcx v6.9.9 and pellesc v4.50) to winXP, and they appear to work too.  Then I decided to upgrade to more age-appropriate versions for winXP.  I chose bcx v7.9.9 and pellesc v6.90.

Then I ran into problems.   winXP tells me that bcx_v7.9.9 is "not a valid win-32 application".  That didn't seem right.  Did the 32bit and 64bit versions get mixed up?  No.  Anyway I started backtracking, and found the bcx_v7.4.5 (and earlier) WERE VALID.  I read the "notes" and couldn't find any mention of deliberately making bcx incompatible with winXP in version 7.4.6 and beyond.  It also appears that about the time when 32bit and 64bit versions began to be distributed together, that the 32bit version lost compatibility (at least with my winXP).

So I am stuck with v7.4.5 for now.  I was hoping that since winXP is an "NT" system, that I might possibly move on up to a more contemporary version of bcx.

One other thing.  I have a version of the 6.9.9 help file from years ago.  I found the bcx v7.4.5 in the archive, but couldn't find an appropriate help file.  Can anybody tell me where they might be found?

cheers, mru

hi Mr BCX,

Your suggestion to dis-aggregate the help file sounds like something appropriate for people more ambitious than I am. 

OTOH, thanks for the reminder about your fast-file-search utility.  One of the things I like about win98 is its FindFiles utility.  It never fails to find what I want.  As for the win10 "search", it is almost useless (for me).  Maybe it's because I turned-off file indexing.  Or, maybe it's just that I don't know how to use it properly.  Whatever, on win10, unless I can remember where I stored something, it becomes lost forever. 

I will take a look at your FFS utility, with the hope that it can replicate the function and usefulness of win98's FindFilles on the win10 system.

cheers, mru

hi Mr BCX,

I did search through the BCX code samples that come with the BCX download, seeking some inspiration on how to solve my typedef problem.  I didn't find anything helpful.

You obviously have a more extensive old-code-library than I have.

I did try one "sneaky trick".  I snipped out the typedef c-code and fixed it up and pasted it into my code (using the $CCODE directive).  I also included the typedef prototype(?) statement.  It all compiled correctly, but wouldn't run.  Apparently my CCODE did not connect properly with my BCX code.

cheers, mru

hi group,

I know what you're thinking...  There is no such thing as an OwnerDraw MsgBox.  Well OK, you're right.  More accurately one might call it a customized BCX Modal Dialog.  But then, customizing is a little like owner-drawing, n'est pas?  You more prosaic groupies might like to call it: Putting Lip-Stick on a BCX Modal Dialog Pig.

My motivation for this was that I got tired of m$'s dull-and-boring MsgBoxes.  They look a little more attractive going from win98 to win10, but one can get tired of the win10 MB's too.  So you may find this a little more colorful.

Also, it's packaged up into a DLL.  That will hopefully make it easier to carry around from app to app.  And also, that makes it usable from vb or vbs.  What?  You say one can't call dll's from vbs?  Think again.   Also note: the odmb will return a string - the caption on the button clicked by "the user" (not the usual IDYES, IDNO, IDOK, etc).

WARNING!  Don't like rounded rectangles?  Then carefully avoid this.  You will probably get nauseated from all the rnded rects in this project. 

Another warning.  There is a massive typedef that goes with this, used to configure the odmb.  I am not happy with ms' msGray, and so every bit of this odmb may be configured with a different color.  But if you don't like to play with configuration or colors, then there is a default configuration scheme built into it. 

PLUSES:  You may configure sizing and positioning.  You may configure the colors.  You may configure the button captions.   

MINUSES:  There is no titlebar and so no dragging the MB around.  There are plenty of code examples on how to drag a window without a titlebar, so if there is an overwhelming demand, that is a feature that might be possible. 

cheers, mru

Developed on win98, with BCX v6.9.9, and PellesC v4.50.  Works on win10, v2H21.

P.S., the usual disclaimer.  The code is offered as is, where is.  I worked on it until it was "good enough" for my purposes.  I may get around some day to code polishing and beautification.  Or maybe not. 

P.P.S.  This is my first foray into the "dialog units" zone.  I confess that I got all tangled up with pixels and dialog units, with the result being a major Excedrin headache.  I probably won't go there again. 

hi Group,

When I write a typedef that looks like this:


Type OWNERDRAWMSGBOXDATA

  crBITMAP as Integer
  crMB_Border as Integer
  crMB_Bkgnd as Integer

  crMB_Text as Integer
 
  crGBtop as Integer
  crGBmdl as Integer
  crGBbot as Integer

  'sMBoxFontFace as String[24] ' not tolerated here
  sMBoxFontFace$[24] AS CHAR
  MBoxFontSize as Integer
 
  'gbCaption1 as String[24]  ' rejected
  'gbCaption2 as String[24]

  gbCaption1$[24] AS CHAR
  gbCaption2$[24] AS CHAR

End Type


I find BCX generating the following "C" code:


typedef struct _OWNERDRAWMSGBOXDATA
{
  int      crBITMAP;
  int      crMB_Border;
  int      crMB_Bkgnd;
  int      crMB_Text;
  int      crGBtop;
  int      crGBmdl;
  int      crGBbot;
  ]        sMBoxFontFace;
  int      MBoxFontSize;
  ]        gbCaption1;
  ]        gbCaption2;
}OWNERDRAWMSGBOXDATA, *LPOWNERDRAWMSGBOXDATA;


Obviously, something is not right there (my first clue was a long page of errors thrown by pellesC).

So, this was my attempt at Take Two:


Type OWNERDRAWMSGBOXDATA

  crBITMAP as Integer
  crMB_Border as Integer
  crMB_Bkgnd as Integer

  crMB_Text as Integer
 
  crGBtop as Integer
  crGBmdl as Integer
  crGBbot as Integer

  'sMBoxFontFace as String[24] ' not tolerated here
  'sMBoxFontFace$[24] AS CHAR  ' this not working either - too long?
  sFntFace$[24] AS CHAR
  MBoxFontSize as Integer
 
  'gbCaption1 as String[24]  ' rejected
  'gbCaption2 as String[24]

  'gbCaption1$[24] AS CHAR  ' not working  - too long?
  'gbCaption2$[24] AS CHAR

  gbCaptn1$[24] AS CHAR 
  gbCaptn2$[24] AS CHAR

End Type


When BCX translated that, it gave me this "C":


typedef struct _OWNERDRAWMSGBOXDATA
{
  int      crBITMAP;
  int      crMB_Border;
  int      crMB_Bkgnd;
  int      crMB_Text;
  int      crGBtop;
  int      crGBmdl;
  int      crGBbot;
  char     sFntFace[24];
  int      MBoxFontSize;
  char     gbCaptn1[24];
  char     gbCaptn2[24];
}OWNERDRAWMSGBOXDATA, *LPOWNERDRAWMSGBOXDATA;


O.K., that looks better.  My guess was that my BCX v6.9.9 did not like variable names longer than 8 characters (for strings in typedefs).   I assume this was corrected in later versions of BCX. 

This was posted only for the benefit of others who may still be using v6.9.9.

cheers, mru

hi group,

It would be nice if when I typed in "mdialog" the search would come up with:

    BCX_MDIALOG

Also, it would be nice if when I typed "settext" the search would offer up:

    BCX_SET_TEXT

cheers, mru

hi Robert,

Quoteyour contribution has been immortally glorified in the Pantheon Of BCX Documentarians.

Wow.  That qualifies as the most elegantly embellished prose of the year (thus far).

Are you perhaps a politician in real life?

cheers, mru