> You should just write about how to use the current version of ooDialog,
version 4.2.0.  
> Things that are hold-overs and only present to support backwards
compatibility of 
> existing programs should be left out of the user's guide. 

Excellent advice, many thanks! 

How about adding a method to .Application to turn off autodetection?
Maybe: .Application~autoDetectionOff

Or, better, how about turning it off merely by the invocation of *any*
.Application method?
Then, if someone wants it on *and* wants to invoke a .Appplication method,
then they could invoke:
  .Application~autoDetectOn

Just a thought...

Oliver

PS: In case you're in any doubt, I will take you advice with some enthusiasm


 

-----Original Message-----
From: Mark Miesfeld [mailto:[email protected]] 
Sent: 15 July 2011 20:04
To: Open Object Rexx Users
Subject: Re: [Oorexx-users] ooDialog - explanation
of.Application~useGlobalConstDir

On Fri, Jul 15, 2011 at 1:11 PM,  <[email protected]> wrote:

> I'm just re-writing some stuff in Chapter 4 of the Guide to explain 
> about the use of .Application~useGlobalConstDir. It needs to be as 
> simple as possible (certainly at chapter four stage). I plan to say 
> something along the lines of:
>
> ----------------------
> "Before version 4.2 of ooDialog, menus were not supported.

Menus *were* supported, but menus were not objects.  Menus were supported,
but most of the features of Windows menus were not supported.


>The previous
> mechanisms for mapping Resource IDs/Names to the underlying Windows  
>mechanisms were directed specifically at dialog controls. Modifying 
>these  mechanisms to handle menus as well was a major task. It turned 
>out to be  easier to introduce a new function for handling all symbolic 
>IDs. This  function is a method on the new ".Application" class (which 
>provides for  application-wide matters). The method is called 
>"useGlobalConstDir, and  takes the name of a *.h file as its main
parameter."
> ----------------------

I would not try to explain *why* it came about.  I would simply say:

if you want to use symbolic resource IDs in your ooDialog programs use the
global .constDir.

That seems pretty simple to me.  <grin>

I wouldn't even put it in relationship to menus.  I would say that where
ever it is that you first introduce the idea of using symbolic IDs.  None of
the example programs shipped with ooDialog 4.2.0 will make use of the dialog
object's constDir attribute.  At some point I will reword the ooDialog
reference to emphasis the global .constDir and de-emphasis the dialog
object's constDir attribute.

In general I would think that any time you find yourself writing along the
lines "in previous versions ..." you should probably think you can eliminate
that section.

You should just write about how to use the current version of ooDialog,
version 4.2.0.  Things that are hold-overs and only present to support
backwards compatibility of existing programs should be left out of the
user's guide.

--
Mark Miesfeld

----------------------------------------------------------------------------
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries,
the creator of the Lean Startup Methodology on "Lean Startup Secrets
Revealed." This video shows you how to validate your ideas, optimize your
ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Oorexx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-users



------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Oorexx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-users

Reply via email to