🚀 go-pugleaf

I had gotten email from somebody about this and in attempting to respond I
lost their address.  Still my response serves to help describe my application
and problems a little bit better:


>	to just try plain C and the API to start.  I bought Petzold's
>	book (it's VERY good, although a bit pricey).  It was exactly
>	what I needed, but it may be too slow for you if you already
>	are experienced with event-driven programming in X.  For me,
>	it was my first taste of it.

Who's Petzold and what is the name of his book?  My book is called _Developing
Windows Applications with Borland C++ 3.1_ (Second edition) by James McCord.
It discusses some basic raw Windows API calls and then delves into OWL.  The,
remainder of the book is like you say, merely a funciton reference.

>	Borland's Resource Workshop (the best!) is so easy to design
>	all of the resources (menus, dialogs, icons, bitmaps etc etc)

I had a lot of trouble trying to do this.  As you say, you don't do this in X.
My problem was that I'd do things in the Resource Workshop (RW) and then try
it out with my program.  First I'd get a "Can't find the .res" messages.  Then
I noticed the RW's File:Preferences setting saying to save the RW changes in a
.res file.  Now why would I not want that one checked?  Then, of course, you
have to deal with remembering that if you make a change in RW you gotta
File:Save Project and then go back to BC++ and re-bind resources.

>	The rest of the hard work was not really windows related
>	(i.e. message handling, dialog boxes, menus, buttons),
>	but rather was application specific.  The way I see it,
>	the classes primarily help with message handling, but
>	I'm old fashioned - I don't like to have 100 5-line
>	functions, one for each message (i.e. member functions
>	of classes). I prefer a large 'switch' to handle each
>	message, so I can see them all at once.  BTW, the
>	giant 10-page long 'switch' statement for messages is
>	somewhat out-of-date now - the idea is to have a
>	table of functions & message ids and the 'switch'	
>	statement then becomes a 5-line loop to lookup the
>	appropriate function and then call it.  This is
>	sort of a hybrid between C and C++, I guess.

To me that's out of date.  Here's a snippet of X/Motif code:

   workButton = XtVaCreateManagedWidget
	 ("work", xmPushButtonWidgetClass, numberForm,
	  XmNlabelString, 		XmStringCreateSimple ("Work #:"),
	  XmNtopAttachment,		XmATTACH_FORM,
	  XmNtopOffset,			3,
	  XmNleftAttatchment,		XmATTACH_FORM,
	  NULL);

   XtAddCallback (workButton, XtNactivateCallback, (XtCallbackProc) dialNumber,
		  (XtPointer) workNbr);

Here I create a pushbutton labeled "Work #:" that is attached on the top and
the left to a "form" container window offset 3 pixels from the top.  Further I
tell X that if this button is pushed then to call the function dialNumber and
pass in the widget (basically a child window in MS Windows terms) named
workNbr.  

The XtAddCallback function insures that dialNumber will be called in the event
of a button push.  There can be many such callbacks all associated with
pushing this single button.  There is no "event loop" to write.  It has been
abstracted away in most causes.  My event loop is:

   XtAppMainLoop (PhoneBookApp);

If you haven't guessed by now I'm writing a phonebook application.  Work #
appears on the tools face along with a single line input box called workNbr.
This is not a dialog box but the face of the phonebook application.  I want it
such that when I push the workButton the program dials the number through the
modem that is contained in the single line edit box called workNbr.  There is 
a similar set of these things for Home number.

BTW, in Motif, a form is a container class widget whose job it is to contain
and layout any widgets or child windows contained there in.  In the above
example, that means that my button is contrained to be attached to the left
and top of the form.  Therefore, if I grab the left hand side of the window
and stretch it out towards the left, this button will float along with it.
This is all called geometry management in X and is what I hope to gain by
using a class lib such as OWL.  Currently I have to specify the pixel relative
offsets of all my child windows and I know I don't want to write code to
resize and replace everything in the event of toplevel window resize event.

>>        How do I write get or set text into a child window?  My application
>>        presents a form-like window that has child windows that are TEXT
>>        input boxes.  I cannot figure out how to put/get text into or out of
>>        these child windows.

>		You don't put or get text from the window itself, you
>		work with a control in the window.  For example, you
>		would put in an 'edit' control if you wanted to be
>		able to enter a title or something else.  When the
>		dialog box is closed, you interrogate that control
>		to get the value.

Perhaps you don't understand my question.  I'm not in a dialog box.  I'm on
the tools face itself.  My tool looks roughly like:

	+--------------------------------------------------+
	| File  Actions                               Help |
	+--------------------------------------------------+
	| Name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
	| Work #: YYYYYYYYYYYYYYYYY  Home #: XXXXXXXXXXXXX |
	| Address:                                         |
	| XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
	| XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
	+--------------------------------------------------+

And I have created the Work # field marked with "YYY"'s like so:

   workNbr = CreateWindow      
	("EDIT",				// Window Class
	"",					// Window Name
	WS_CHILD | WS_VISIBLE | WS_BORDER,	// Window Style
	65,					// X Coordinate
	40,					// Y Coordinate
	130,					// Width
	25,					// Height
	window,					// Parent Window
	NULL,					// Menu
	instance,				// Instance
	NULL);					// Parameters


Given this workNbr child window, how does one write to it or get stuff out of
it?

>		You can SetWindowText() and GetWindowText() to
>		change the title (caption) of a window.

Again, I'm not interested in setting the title or caption of a window and I'm
not in a dialog box.  I want to get to a child windows textual value itself.

>>        How does one put text into a dialog box?  I want to do a familiar "Are
>>        you sure you want to delete 'thing being deleted'" type of dialog.  I
>>        need to construct the message string for the dialog box but I don't
>>        know how to do that.
>		You can do a lot with MessageBox(), i.e.:
>		if(MessageBox(hwnd,"are you sure you want to delete it ?",
>				"file XXX.YYY",MB_YESNO)==IDYES){
>			unlink("xxx.yyy");
>		}

This is a confusing thing for me.  As you know, in Motif you build your own
dialogboxes programmatically (although there are some standard canned ones
that are useful).  Why would I make a dialogBox in the RW if I could simply do
this?  To answer my own question: Because the RW Dialog Editor is really only
for more complicated dialog boxes.  And that's probably because to allow you
to build your own dialog boxes programmatically would probably require that
you have some sort of geometry management which MS Windows doesn't provide.

My simple solution is the MessageBox route.  There is nothing else in the
dialog but the message needs to be constructed with the persons name so I can
get away with it this time.  But what if I had a more complicated dialog box
and wished to put a message into it which could only be determined at run
time?

>>        How can one get an icon image or a bmp into a button?
>		This is something which is not part of the standard
>		Windows API or SDK.  It is a Borland feature - they
>		have some special controls in OWL (they are selectable
>		from Resource Workshop).  Look at the collection of
>		examples and DOC files in your Borland directories
>		for samples on how to do this.  I recall a file
>		BTBTN.C etc referring to this.  

Well I have Quicken for Windows 2.0 and it has a full color button bar across
the top.  Is it a Borland application?

I cannot look up this file.  Remember I don't have AF or OWL yet.  No such
file appears on my system by that name (or anthing close to it).

>>        I tried making what would be called a staticTextWidget in X but it's
>>        color is wrong.  I want the color for a staticTextWiget to be the
>>        application's background color, not a TEXT boxes' input color.

>		When you create a window (actually when you register
>		the window class), you specify the background colour
>		to be whatever you like.  You can get the user's
>		preferred background colour using a colour of
>		COLOR_WINDOW+1.

This staticTextWidget I speak of is the "Name" field in the above diagram.  I
create my main window using a window class that has:

      windowClass.hbrBackground = COLOR_APPWORKSPACE + 1; 

However the Name label field is created as a child window to the main window.
Am I to understand that I must create another windowClass structure and set
it's hbrBackground again?

>>        How would I change the input editing semantics of these text input
>>        areas to be as I specify.  I like emacs type editing.  I get this
>>        easily in X via translation table and like to implement this in my
>>        program.

>		I don't think you can do this.  The 'edit' class of
>		control uses Windows CUA-type controls.  I don't
>		think you can make it work any other way, other
>		than writing your own 'edit' class'

Again, I have Word Perfect for Windows and it sports both the standard Windows
CUA-type of editing style and Word Perfect's old editing style.  Therefore it
is possible but it might, as you say, require writing my own edit class.
Still EMACs editing style is fairly popular and I would hope that someone has
already done this.