[Oorexx-users] (no subject)

[Cyril Randles]

-- 
Kind regards
___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

Re: [Oorexx-users] (no subject)

[Les Koehler]

Chip,

The trouble with this suggestion is that a simple typo could *create* a 
new directory, which must then be manually deleted.
Of course one could make the same mistrake with "mkdir" itself, but 
there the irror would be more obvious :-)

Les

On 2/4/2016 1:26 PM, Chip Davis wrote:
> IMHO this is a software blivet (Def: "50 kg of manure in a 40 kg bag").
>
> The DIRECTORY() function is trying to do three things with the ability
> to return only one string:
> 1. Return the current directory
> 2. Create a new directory
> 3. Change to a new directory
>
> This is at least one operation too many, because the returned string
> that makes sense for one operation does not make sense for others.
>
> I argue that is should _always_ return the current directory, because
> that is its default behavior, and to make it easy to revert to that
> directory after (potentially) changing it.
>
> That does not eliminate the possibility of indicating whether or not
> the creation of a new directory was successful.
>
> So if I had designed that routine, here is the set of behaviors:
>
> DIRECTORY() returns current directory
>
> DIRECTORY('existing-dir') returns current directory, then makes
> 'existing-dir' the current directory
>
> DIRECTORY('new_dir') returns current directory, then creates
> 'new-dir', then makes 'new-dir' the current directory IFF creation
> successful
>
> Because of the aggregation of the three operations, when changing
> directories a prudent programmer should always compare the response
> from DIRECTORY() to see if it matches the argument passed.  If so, the
> operation was successful.
>
> If not, either something happened to 'existing-dir', or the creation
> of 'new-dir' was not successful.  Regardless, further operations to
> that directory should not be attempted.
>
> This is no more effort that testing for a null string returned value
> and far more consistent.
>
> -Chip-
>
> On 2/4/2016 10:42 AM, Les Koehler wrote:
>> I find the Regina OS/2 Help just as  confusing! First, it starts with a
>> simple declarative and non-contradictory sentence:
>>
>> - clip -
>> Returns the current directory for the running process, and optionally
>> changes directory to the specified new directory.
>> - eclip -
>>
>> I've seen this technique in ooRexx before and it's quite logical. It
>> provides, in one operation, the name of the directory to restore *and*
>> switches to the new (presumably valid) directory. Neat!
>>
>> However, the sentences that follow *modify* the previous declarative
>> sentence, thus creating confusion:
>>
>> - clip -
>> If the new directory
>> exists, and the change to new directory succeeds, the new directory is
>> returned. If the new directory does not exist or an error occurred changing
>> to that new directory, the empty string is returned.
>> - eclip -
>>
>> The original Object Rexx Beta Draft was much clearer:
>>
>> - clip -
>> returns the current directory, first changing it to NewDirectory if an
>> argument is supplied and the named directory exists. If NewDirectory is
>> not specified, the name of the current directory is returned. Otherwise,
>> an attempt is made to change to the specified NewDirectory. If
>> successful, the name of the NewDirectory is returned; if an error
>> occurred, null is returned.
>> - eclip -
>>
>> Maybe its just me, but this is a prime example of non-professional
>> writers trying to *improve* what an expert writer wrote to begin with!
>> Generally speaking, we should guard against such changes.
>>
>> Les
>>
>>
>>
>> On 2/4/2016 2:59 AM, Jon Wolfers wrote:
>>> Hi Bert,
>>>
>>> this thread has suddenly become quite complex and sensitive.  I hope that
>>> the nuances in my reply come through.
>>>
>>> Firstly, I did see your response about your experience on VM.  I would not
>>> expect VM to behave in the same way as Windows.  The filesystem is
>>> different.  It is nearly a quarter century since I had my hands on a VM
>>> system, but I don't remember there being a directory structure at all just
>>> filename filetype and Disk[mode] - perhaps I'm remembering wrong.
>>>
>>> Secondly, the code as you posted it doesn't demonstrate how the directory
>>> function actually behaved at that  time, in fact, reading your post I can't
>>> even be certain of how you expected it to behave.  I read several
>>> possibilities into this scenario, including one where the documentation was
>>> just as ambiguous then, and the interpreter writers intention was the same
>>> then as the observed behaviour today.
>>>
>>> You say "all implementations of the language should match" and you go on to
>>> establish a principle of prior precedent.  Now I don't know what you mean
>>> by 'should', I would agree that *gratuitous* change should be avoided.  I
>>> think that the reason that this is desirable is not because the language
>>> needs to be fixed in stone, but because changes cause programs out there to
>>> 

Re: [Oorexx-users] (no subject)

[Les Koehler]

I find the Regina OS/2 Help just as  confusing! First, it starts with a 
simple declarative and non-contradictory sentence:

- clip -
Returns the current directory for the running process, and optionally
changes directory to the specified new directory.
- eclip -

I've seen this technique in ooRexx before and it's quite logical. It 
provides, in one operation, the name of the directory to restore *and* 
switches to the new (presumably valid) directory. Neat!

However, the sentences that follow *modify* the previous declarative 
sentence, thus creating confusion:

- clip -
If the new directory
exists, and the change to new directory succeeds, the new directory is
returned. If the new directory does not exist or an error occurred changing
to that new directory, the empty string is returned.
- eclip -

The original Object Rexx Beta Draft was much clearer:

- clip -
returns the current directory, first changing it to NewDirectory if an 
argument is supplied and the named directory exists. If NewDirectory is 
not specified, the name of the current directory is returned. Otherwise, 
an attempt is made to change to the specified NewDirectory. If 
successful, the name of the NewDirectory is returned; if an error 
occurred, null is returned.
- eclip -

Maybe its just me, but this is a prime example of non-professional 
writers trying to *improve* what an expert writer wrote to begin with! 
Generally speaking, we should guard against such changes.

Les



On 2/4/2016 2:59 AM, Jon Wolfers wrote:
> Hi Bert,
>
> this thread has suddenly become quite complex and sensitive.  I hope that
> the nuances in my reply come through.
>
> Firstly, I did see your response about your experience on VM.  I would not
> expect VM to behave in the same way as Windows.  The filesystem is
> different.  It is nearly a quarter century since I had my hands on a VM
> system, but I don't remember there being a directory structure at all just
> filename filetype and Disk[mode] - perhaps I'm remembering wrong.
>
> Secondly, the code as you posted it doesn't demonstrate how the directory
> function actually behaved at that  time, in fact, reading your post I can't
> even be certain of how you expected it to behave.  I read several
> possibilities into this scenario, including one where the documentation was
> just as ambiguous then, and the interpreter writers intention was the same
> then as the observed behaviour today.
>
> You say "all implementations of the language should match" and you go on to
> establish a principle of prior precedent.  Now I don't know what you mean
> by 'should', I would agree that *gratuitous* change should be avoided.  I
> think that the reason that this is desirable is not because the language
> needs to be fixed in stone, but because changes cause programs out there to
> break.
>
> I don't know how the directory BIF worked on Object Rexx for OS/2 or the
> system interpeter on VM, but I have verified to my satisfaction by looking
> at the code in the ooRexx repository that the current behaviour has been
> present on ooRexx for Windows and Linux for at least the last eight years,
> and possibly more.
>
> I don't know how other interpreters work - although looking at the manuals
> I have for Personal Rexx & Kexx I see that they each handle this very
> differently.  Regina appears to have a directory BIF for OS/2 only and the
> helpfile seems to indicate that the behaviour in Regina for OS/2 is exactly
> the same as what happens in ooRexx currently.  I hope Mark doesn't mind,
> but I quote the Regina OS/2 help below.
>
> Now, given that it isn't possible to have all rexx interpreters working
> exactly the same, because we see such a spread of behaviour, and that the
> current behaviour in ooRexx for Windows and Linux has been in place for a
> long time, I would say that changing this behaviour to match some behaviour
> that might have existed on some interpreter on some platform in the past
> would break more currently active code than recognising that this change
> may have occurred in the past and that the helpfile is ambiguous and
> correcting the helpfile suitably.
>
> I hope that that makes my position on this clear.  Sorry if it opens a can
> of worms.
>
> Jon
>
>
> Regina's Directory BIF for OS/2 helpfile:
>
>> DIRECTORY([new directory]) - (OS/2)
>> Returns the current directory for the running process, and optionally
>> changes directory to the specified new directory. If the new directory
>> exists, and the change to new directory succeeds, the new directory is
>> returned. If the new directory does not exist or an error occurred changing
>> to that new directory, the empty string is returned.
>
>
>
> On 4 February 2016 at 02:03, Bertram Moshier 
> wrote:
>
>> Hi Jon,
>>
>> .
>>> I would say that this is a documentation bug as the documentation lists
>>> two different behaviours which can't both be right, and the code only
>>> displays 

Re: [Oorexx-users] (no subject)

[Walter Pachl]

Reasonable (but wishful) thinking...
This reminds me of the value bif
(returns current value and optionally sets the new value)
Greetings
Walter


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

Re: [Oorexx-users] (no subject)

[Jon Wolfers]

- clip -
returns the current directory, first changing it to NewDirectory if an
argument is supplied and the named directory exists. If NewDirectory is not
specified, the name of the current directory is returned. Otherwise, an
attempt is made to change to the specified NewDirectory. If successful, the
name of the NewDirectory is returned; if an error occurred, null is
returned.
- eclip -

Yes, I agree the text you found is clearer.

Jon

On 4 February 2016 at 15:42, Les Koehler  wrote:

> I find the Regina OS/2 Help just as  confusing! First, it starts with a
> simple declarative and non-contradictory sentence:
>
> - clip -
> Returns the current directory for the running process, and optionally
> changes directory to the specified new directory.
> - eclip -
>
> I've seen this technique in ooRexx before and it's quite logical. It
> provides, in one operation, the name of the directory to restore *and*
> switches to the new (presumably valid) directory. Neat!
>
> However, the sentences that follow *modify* the previous declarative
> sentence, thus creating confusion:
>
> - clip -
> If the new directory
> exists, and the change to new directory succeeds, the new directory is
> returned. If the new directory does not exist or an error occurred changing
> to that new directory, the empty string is returned.
> - eclip -
>
> The original Object Rexx Beta Draft was much clearer:
>
> - clip -
> returns the current directory, first changing it to NewDirectory if an
> argument is supplied and the named directory exists. If NewDirectory is not
> specified, the name of the current directory is returned. Otherwise, an
> attempt is made to change to the specified NewDirectory. If successful, the
> name of the NewDirectory is returned; if an error occurred, null is
> returned.
> - eclip -
>
> Maybe its just me, but this is a prime example of non-professional writers
> trying to *improve* what an expert writer wrote to begin with! Generally
> speaking, we should guard against such changes.
>
> Les
>
>
>
> On 2/4/2016 2:59 AM, Jon Wolfers wrote:
>
>> Hi Bert,
>>
>> this thread has suddenly become quite complex and sensitive.  I hope that
>> the nuances in my reply come through.
>>
>> Firstly, I did see your response about your experience on VM.  I would not
>> expect VM to behave in the same way as Windows.  The filesystem is
>> different.  It is nearly a quarter century since I had my hands on a VM
>> system, but I don't remember there being a directory structure at all just
>> filename filetype and Disk[mode] - perhaps I'm remembering wrong.
>>
>> Secondly, the code as you posted it doesn't demonstrate how the directory
>> function actually behaved at that  time, in fact, reading your post I
>> can't
>> even be certain of how you expected it to behave.  I read several
>> possibilities into this scenario, including one where the documentation
>> was
>> just as ambiguous then, and the interpreter writers intention was the same
>> then as the observed behaviour today.
>>
>> You say "all implementations of the language should match" and you go on
>> to
>> establish a principle of prior precedent.  Now I don't know what you mean
>> by 'should', I would agree that *gratuitous* change should be avoided.  I
>>
>> think that the reason that this is desirable is not because the language
>> needs to be fixed in stone, but because changes cause programs out there
>> to
>> break.
>>
>> I don't know how the directory BIF worked on Object Rexx for OS/2 or the
>> system interpeter on VM, but I have verified to my satisfaction by looking
>> at the code in the ooRexx repository that the current behaviour has been
>> present on ooRexx for Windows and Linux for at least the last eight years,
>> and possibly more.
>>
>> I don't know how other interpreters work - although looking at the manuals
>> I have for Personal Rexx & Kexx I see that they each handle this very
>> differently.  Regina appears to have a directory BIF for OS/2 only and the
>> helpfile seems to indicate that the behaviour in Regina for OS/2 is
>> exactly
>> the same as what happens in ooRexx currently.  I hope Mark doesn't mind,
>> but I quote the Regina OS/2 help below.
>>
>> Now, given that it isn't possible to have all rexx interpreters working
>> exactly the same, because we see such a spread of behaviour, and that the
>> current behaviour in ooRexx for Windows and Linux has been in place for a
>> long time, I would say that changing this behaviour to match some
>> behaviour
>> that might have existed on some interpreter on some platform in the past
>> would break more currently active code than recognising that this change
>> may have occurred in the past and that the helpfile is ambiguous and
>> correcting the helpfile suitably.
>>
>> I hope that that makes my position on this clear.  Sorry if it opens a can
>> of worms.
>>
>> Jon
>>
>>
>> Regina's Directory BIF for OS/2 helpfile:

Re: [Oorexx-users] (no subject)

[Jon Wolfers]

Hi Bert,

this thread has suddenly become quite complex and sensitive.  I hope that
the nuances in my reply come through.

Firstly, I did see your response about your experience on VM.  I would not
expect VM to behave in the same way as Windows.  The filesystem is
different.  It is nearly a quarter century since I had my hands on a VM
system, but I don't remember there being a directory structure at all just
filename filetype and Disk[mode] - perhaps I'm remembering wrong.

Secondly, the code as you posted it doesn't demonstrate how the directory
function actually behaved at that  time, in fact, reading your post I can't
even be certain of how you expected it to behave.  I read several
possibilities into this scenario, including one where the documentation was
just as ambiguous then, and the interpreter writers intention was the same
then as the observed behaviour today.

You say "all implementations of the language should match" and you go on to
establish a principle of prior precedent.  Now I don't know what you mean
by 'should', I would agree that *gratuitous* change should be avoided.  I
think that the reason that this is desirable is not because the language
needs to be fixed in stone, but because changes cause programs out there to
break.

I don't know how the directory BIF worked on Object Rexx for OS/2 or the
system interpeter on VM, but I have verified to my satisfaction by looking
at the code in the ooRexx repository that the current behaviour has been
present on ooRexx for Windows and Linux for at least the last eight years,
and possibly more.

I don't know how other interpreters work - although looking at the manuals
I have for Personal Rexx & Kexx I see that they each handle this very
differently.  Regina appears to have a directory BIF for OS/2 only and the
helpfile seems to indicate that the behaviour in Regina for OS/2 is exactly
the same as what happens in ooRexx currently.  I hope Mark doesn't mind,
but I quote the Regina OS/2 help below.

Now, given that it isn't possible to have all rexx interpreters working
exactly the same, because we see such a spread of behaviour, and that the
current behaviour in ooRexx for Windows and Linux has been in place for a
long time, I would say that changing this behaviour to match some behaviour
that might have existed on some interpreter on some platform in the past
would break more currently active code than recognising that this change
may have occurred in the past and that the helpfile is ambiguous and
correcting the helpfile suitably.

I hope that that makes my position on this clear.  Sorry if it opens a can
of worms.

Jon


Regina's Directory BIF for OS/2 helpfile:

> DIRECTORY([new directory]) - (OS/2)
> Returns the current directory for the running process, and optionally
> changes directory to the specified new directory. If the new directory
> exists, and the change to new directory succeeds, the new directory is
> returned. If the new directory does not exist or an error occurred changing
> to that new directory, the empty string is returned.



On 4 February 2016 at 02:03, Bertram Moshier 
wrote:

> Hi Jon,
>
> .
>> I would say that this is a documentation bug as the documentation lists
>> two different behaviours which can't both be right, and the code only
>> displays one of these behaviors.
>
>
> I think my earlier email about find a VM/CMS example went though, but in
> case it didn't (I sent it from a tablet).  I found an example in my old
> notes, while at Cray Research, Inc, of using it as:
>
> Current_Dir = directory(New_Dir)  where New_Dir was a valid location.
>
> I also think I successfully used this coding using classic Rexx under OS/2
> Warp, but have yet to find my old OS/2 Warp drives.
>
> As all implementations of the language should match and VM/CMS, OS/2 Warp,
> MVS, etc all came earlier, I'd say the documentation and code both are off
> in their own ways.  The documentation needs to be clear, obviously.  Also
> the implementation should allow functions, such as the directory, to
> function the same regardless.
>
> Would this be two bug reports or one for two areas?
>
> Bert.
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Oorexx-users mailing list
> Oorexx-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-users
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor 

Re: [Oorexx-users] (no subject)

[Moritz Hoffmann]

On Thu, Feb 4, 2016 at 8:59 AM, Jon Wolfers  wrote:

>
> Now, given that it isn't possible to have all rexx interpreters working
> exactly the same, because we see such a spread of behaviour, and that the
> current behaviour in ooRexx for Windows and Linux has been in place for a
> long time, I would say that changing this behaviour to match some behaviour
> that might have existed on some interpreter on some platform in the past
> would break more currently active code than recognising that this change
> may have occurred in the past and that the helpfile is ambiguous and
> correcting the helpfile suitably.
>

I fully agree. We should be more concerned about not breaking ooRexx
instead of making it compatible to some other version of Rexx. I'd vote for
adjusting the documentation and leave it as that. We could even add a note
saying that ooRexx's directory bif might be different from old versions of
Rexx.

Moritz
-- 
Moritz Hoffmann;
http://antiguru.de/
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

[Oorexx-users] (no subject)

[Bertram Moshier]

Hi Jon,

.
> I would say that this is a documentation bug as the documentation lists
> two different behaviours which can't both be right, and the code only
> displays one of these behaviors.


I think my earlier email about find a VM/CMS example went though, but in
case it didn't (I sent it from a tablet).  I found an example in my old
notes, while at Cray Research, Inc, of using it as:

Current_Dir = directory(New_Dir)  where New_Dir was a valid location.

I also think I successfully used this coding using classic Rexx under OS/2
Warp, but have yet to find my old OS/2 Warp drives.

As all implementations of the language should match and VM/CMS, OS/2 Warp,
MVS, etc all came earlier, I'd say the documentation and code both are off
in their own ways.  The documentation needs to be clear, obviously.  Also
the implementation should allow functions, such as the directory, to
function the same regardless.

Would this be two bug reports or one for two areas?

Bert.
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

Re: [Oorexx-users] (no subject)

[Oliver Sims]

An AskDialog always comes up in the centre of the screen. When you hit “Yes” or 
“No” on the AskDialog, the dialog ends and so disappears from the screen.

 

Now, your code has several AskDialogs appearing one after the other. And if you 
move the first AsklDialog from the centre, then hit either Yes or No, then that 
dialog ends and closes - i.e. disappears. BUT - your code  immediately brings 
up a *new* AskDialog, which appears, as did the first, In the centre of the 
screen. 

 

This sequence looks as if the original AskDialog has moved. But it hasn’t – it 
just ended and the new one appeared.

 

Maybe you need to build a dialog that has some radio buttons in it, so you can 
select all the options you need, and then press Enter (or whatever). 

 

If it would help (let me know) I’ll see if I can build such a dialog for you as 
an example. However, unfortunately I’m not able at this point to *promise* to 
do so any time soon. 

 

Atb,

Oliver

 

 

 

From: Bertram Moshier [mailto:bertrammosh...@gmail.com] 
Sent: 27 February 2015 22:09
To: oorexx-users@lists.sourceforge.net
Subject: [Oorexx-users] (no subject)

 

Hello again Oliver,

 Sounds a bit weird - don?t know if I can help, but what kind of dialog is it 
 ? i.e. what?s its superclass (e.g. UserDialog)?

 

Oh, weird?!  Ah.  Well, I'm learning to the ooDialog by using bits and pieces 
of sample code.  Thus maybe I'm incorrectly using a call or something.  Here is 
a snippet of the code.

Background:  This Rexx program allows the user to set the Power Plan for the 
system.  Originally written only to support passed parameters (e.g. PowerPlan 
High or PowerPlan GoodNight, I added Dialog in two places.  One displays a list 
of the power plans and allows the user to select one of them.  The other 
toggles between two plans (High Performance and a Good Night plan I created).

Code Snippet:

if GBL.parameter.0 = 2 ,
   ((abbrev('DIALOG',upper(GBL.parameter.1),1)| ,
 abbrev('DIALOG',upper(GBL.parameter.2),1)),
(abbrev('TOGGLE',upper(GBL.parameter.1),1)| ,
 abbrev('TOGGLE',upper(GBL.parameter.2),1)))then do

  if PowerPlanName.DialogAnswer  HighPerf,
 PowerPlanName.DialogAnswer  GoodNight  then do
call !!Say_Directed 4,'w','Current ' || PowerPlanName.DialogAnswer || ' 
is not valid for Dialog Toggle.  Changing the current power plan to ' || 
HighPerf || ' and continuing.'
PowerCMD '-setactive' HighPerfGUID
DialogAnswer = HighPerfPCL
end

  msg = 'Toggle Power Plan?  Yes or No (Quit)' || 
.endOfLine~copies(2) || ,
'Current Power Plan is' PowerPlanName.DialogAnswer

  do while AskDialog(msg, 'Y')
select
  when PowerPlanName.DialogAnswer = HighPerf then do
PowerCMD '-setactive' GoodNightGUID
call !!Say_Directed 10,'i','Power plan changed to Good Night (' || 
GoodNightGUID || ').  Reqest is: Dialog Toggle.'
PowerPlanName.DialogAnswer = GoodNight
end
  when PowerPlanName.DialogAnswer = GoodNight then do
PowerCMD '-setactive' HighPerfGUID
call !!Say_Directed 10,'i','Power plan changed to High Performance (' 
|| HighPerfGUID || ').  Reqest is: Dialog Toggle.'
PowerPlanName.DialogAnswer = HighPerf
end
  otherwise do
nop
end
  end
msg = 'Toggle Power Plan?  Yes or No (Quit)' || 
.endOfLine~copies(2) || ,
  'Current Power Plan is' PowerPlanName.DialogAnswer
end
  call !!Say_Directed 1201,'i','Dialog terminated.  Current power plan is ' || 
PowerPlanName.DialogAnswer || '.'

  call !!EOJ 0
  end
 else if GBL.parameter.0 = 2 then do
call !!Say_Directed 1200,'e','Invalid double parameter combination.  
They must be Dialog and Toggle.'
call !!EOJ 1200
end  

 

I chose the AskDialog call because all I need is a Yes or No (Yes, toggle; No, 
end).  Maybe I'm expecting too much from AskDialog to stay where put, as it is 
a message.  If so,

*   What is a better call given the toggle idea and the existing code?
*   What is a good way to learn how to use ooDialog? 
*   Also a good resource compiler?

Thank you, Oliver, for your two replies thus far. :-)

Bert.

 

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

[Oorexx-users] (no subject)

[Bertram Moshier]

Hello again Oliver,

 Sounds a bit weird - don?t know if I can help, but what kind of dialog is
 it ? i.e. what?s its superclass (e.g. UserDialog)?


Oh, weird?!  Ah.  Well, I'm learning to the ooDialog by using bits and
pieces of sample code.  Thus maybe I'm incorrectly using a call or
something.  Here is a snippet of the code.

Background:  This Rexx program allows the user to set the Power Plan for
the system.  Originally written only to support passed parameters (e.g.
PowerPlan High or PowerPlan GoodNight, I added Dialog in two places.  One
displays a list of the power plans and allows the user to select one of
them.  The other toggles between two plans (High Performance and a Good
Night plan I created).

Code Snippet:

if GBL.parameter.0 = 2 ,
((abbrev('DIALOG',upper(GBL.parameter.1),1)| ,
  abbrev('DIALOG',upper(GBL.parameter.2),1)),
 (abbrev('TOGGLE',upper(GBL.parameter.1),1)| ,
  abbrev('TOGGLE',upper(GBL.parameter.2),1)))then do

   if PowerPlanName.DialogAnswer  HighPerf,
  PowerPlanName.DialogAnswer  GoodNight  then do
 call !!Say_Directed 4,'w','Current ' || PowerPlanName.DialogAnswer ||
 ' is not valid for Dialog Toggle.  Changing the current power plan to '
 || HighPerf || ' and continuing.'
 PowerCMD '-setactive' HighPerfGUID
 DialogAnswer = HighPerfPCL
 end

   msg = 'Toggle Power Plan?  Yes or No (Quit)' ||
 .endOfLine~copies(2) || ,
 'Current Power Plan is' PowerPlanName.DialogAnswer

   do while AskDialog(msg, 'Y')
 select
   when PowerPlanName.DialogAnswer = HighPerf then do
 PowerCMD '-setactive' GoodNightGUID
 call !!Say_Directed 10,'i','Power plan changed to Good Night (' ||
 GoodNightGUID || ').  Reqest is: Dialog Toggle.'
 PowerPlanName.DialogAnswer = GoodNight
 end
   when PowerPlanName.DialogAnswer = GoodNight then do
 PowerCMD '-setactive' HighPerfGUID
 call !!Say_Directed 10,'i','Power plan changed to High Performance
 (' || HighPerfGUID || ').  Reqest is: Dialog Toggle.'
 PowerPlanName.DialogAnswer = HighPerf
 end
   otherwise do
 nop
 end
   end
 msg = 'Toggle Power Plan?  Yes or No (Quit)' ||
 .endOfLine~copies(2) || ,
   'Current Power Plan is' PowerPlanName.DialogAnswer
 end
   call !!Say_Directed 1201,'i','Dialog terminated.  Current power plan is
 ' || PowerPlanName.DialogAnswer || '.'

   call !!EOJ 0
   end
  else if GBL.parameter.0 = 2 then do
 call !!Say_Directed 1200,'e','Invalid double parameter
 combination.  They must be Dialog and Toggle.'
 call !!EOJ 1200
 end


I chose the AskDialog call because all I need is a Yes or No (Yes, toggle;
No, end).  Maybe I'm expecting too much from AskDialog to stay where put,
as it is a message.  If so,

   - What is a better call given the toggle idea and the existing code?
   - What is a good way to learn how to use ooDialog?
   - Also a good resource compiler?

Thank you, Oliver, for your two replies thus far. :-)

Bert.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

[Oorexx-users] (no subject)

[Bertram Moshier]

Hello David and all others,

 The rexxc program (supplied with ooRexx) can remove the ability of
 anyone from seeing the original source code. But be sure to save a copy
 of the original source as you can not get it back from the code produced
 by rexxc

Thank you so very much!

Bert.
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

[Oorexx-users] (no subject)

[Mark Miesfeld]

The Open Object Rexx Development Team is proud to announce the
availability of ooRexx 4.1.2. This is a bug fix only release, with 15
to 20 bugs fixed.

Installation packages for ooRexx are available immediately on
SourceForge. You can download ooRexx 4.1.2 from:

http://sourceforge.net/projects/oorexx/files/oorexx/4.1.2/

Complete documentation in PDF and HTML format can be downloaded from:

http://sourceforge.net/projects/oorexx/files/oorexx-docs/4.1.2/

Download the CHANGES document, in the ooRex files area, to see the
list of fixes. The _ReadMe.pdf or _ReadMe.html file contain additional
information concerning the release.  If you discover bugs please open
a bug report at:

http://sourceforge.net/p/oorexx/bugs/

--
The ooRexx Development Team

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users