We have several legacy Clipper applications that have been converted to 
xBase++, and we are trying to address a problem where users are able to 
press Escape to bypass the VALID (postblock).  We found the above 
referenced PDR in the KB, but this issue has apparently been open for a 
very long time.

We're wondering what others have done to address this issue.  We 
considered modifying GetReader in GetSys.prg (possibly to use :Cargo), 
but that seemed drastic and we weren't sure how to link the application 
to replace the default GetSys.

Any assistance would be appreciated.

Patrick,

>We have several legacy Clipper applications that have been converted to 
>xBase++, and we are trying to address a problem where users are able to 
>press Escape to bypass the VALID (postblock).  We found the above 
>referenced PDR in the KB, but this issue has apparently been open for a 
>very long time.

I'm not sure if this PDR applies to your issue or not. The issue described 
in this PDR is simply the fact that the GetActive():Original value changes 
to the same value as the GetActive():Buffer value, when data is entered, and 
doesn't keep its "Original" value.

The fact that the ESC key will always cancel a Read -- while ignoring and 
not executing the Valid clause -- is the same behavior as you will get in 
Clipper. So I'm not quite sure what your actual issue is.

>We're wondering what others have done to address this issue.  We 
>considered modifying GetReader in GetSys.prg (possibly to use :Cargo), 
>but that seemed drastic and we weren't sure how to link the application 
>to replace the default GetSys.

I'm not sure if you want to change the GetReader in the "GetSys.prg" file, 
but if you do, simply do the following in the "\Source\Runtime\Sys\" 
directory:

PBuild Project.xpj

Then copy the file: "\Source\Runtime\Sys\Lib\XppSys.dll" into your Runtime 
and Lib directories and "\Source\Runtime\Sys\Lib\XppSys.lib" in the Lib 
directory. You may want to keep a copy of any modified and created files 
in a separate location, though, as updating to a newer (or restoring an 
older) Xbase++ version will eradicate those files and any changes you may 
have made.

If you still use Xbase++ 1.9 (or earlier), then the "GetSys.prg" file will 
be in the "\XppW32\Source\Sys\" directory, while the corresponding Project 
file will be here: "\XppW32\Source\DLL\Project.xpj". The resulting DLL and 
LIB files will be in the "\XppW32\Source\DLL\Lib" directory.

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net

On 8/27/2015 4:03 PM, Andreas Gehrs-Pahl wrote:
> Patrick,
>
>> We have several legacy Clipper applications that have been converted to
>> xBase++, and we are trying to address a problem where users are able to
>> press Escape to bypass the VALID (postblock).  We found the above
>> referenced PDR in the KB, but this issue has apparently been open for a
>> very long time.
>
> I'm not sure if this PDR applies to your issue or not. The issue described
> in this PDR is simply the fact that the GetActive():Original value changes
> to the same value as the GetActive():Buffer value, when data is entered, and
> doesn't keep its "Original" value.
>
> The fact that the ESC key will always cancel a Read -- while ignoring and
> not executing the Valid clause -- is the same behavior as you will get in
> Clipper. So I'm not quite sure what your actual issue is.
>
>> We're wondering what others have done to address this issue.  We
>> considered modifying GetReader in GetSys.prg (possibly to use :Cargo),
>> but that seemed drastic and we weren't sure how to link the application
>> to replace the default GetSys.
>
> I'm not sure if you want to change the GetReader in the "GetSys.prg" file,
> but if you do, simply do the following in the "\Source\Runtime\Sys\"
> directory:
>
> PBuild Project.xpj
>
> Then copy the file: "\Source\Runtime\Sys\Lib\XppSys.dll" into your Runtime
> and Lib directories and "\Source\Runtime\Sys\Lib\XppSys.lib" in the Lib
> directory. You may want to keep a copy of any modified and created files
> in a separate location, though, as updating to a newer (or restoring an
> older) Xbase++ version will eradicate those files and any changes you may
> have made.
>
> If you still use Xbase++ 1.9 (or earlier), then the "GetSys.prg" file will
> be in the "\XppW32\Source\Sys\" directory, while the corresponding Project
> file will be here: "\XppW32\Source\DLL\Project.xpj". The resulting DLL and
> LIB files will be in the "\XppW32\Source\DLL\Lib" directory.
>
> Hope that helps,
>
> Andreas
>
Andreas,

Thanks for the quick response. Doesn't that PDR seem applicable because 
the :undo method doesn't have the original value to restore when it's 
triggered in GetApplyKey (assuming Escape was pressed)? Am I missing 
something?

I may try your instructions for modifying GetSys just as an exercise, 
but it would be nice if we didn't actually have to deploy anything like 
that.

Patrick,

>Thanks for the quick response. Doesn't that PDR seem applicable because 
>the :undo method doesn't have the original value to restore when it's 
>triggered in GetApplyKey (assuming Escape was pressed)? Am I missing 
>something?

I haven't used @ Say/Get for a very long time, so I'm not sure what the best 
way would be to fix your problem, but it seems to me that Clipper 5.2e and 
Xbase++ 2.00.625 behave the same way (out of the box), with the exception of 
the oGet:Original iVar, which (in Xbase++) is updated to the oGet:Buffer 
value whenever the oGet object loses focus, while in Clipper it is updated 
to the oGet:Buffer value only when the oGet object receives focus.

In Clipper as well as Xbase++, the value of an oGet object is reset to its 
original/previous value (that it had before the object received focus), 
when the ESC key is pressed (to cancel the Read operation). Also, neither 
with Clipper nor with Xbase++, will any of the other oGet objects -- that 
don't have input focus at the time when the ESC key is pressed -- changed 
back (or reset) to a previous (or "original") value.

So, if you want to reset all Get objects to their original values if the 
Read operation is canceled (with ESC or any other way), you would have to 
have custom code in place that resets all oGet objects (or at least all 
their associated variables) to their original values, no matter if you use 
Clipper or Xbase++, and you should be able to continue to use that same 
Clipper code in Xbase++.

Of course, a working example program that can be compiled in Clipper and 
Xbase++, and which shows the (different or wrong) behavior, would be the 
best way for getting more specific help in this forum.

>I may try your instructions for modifying GetSys just as an exercise, 
>but it would be nice if we didn't actually have to deploy anything like 
>that.

If your change to GetSys fixes your problem, maybe you would like to post it 
here, so that others can utilize it, and maybe it will help Alaska to create 
a permanent fix, if one is required.

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net

Patrick, I´m including getsys.prg and getsysX.prg in my project to work the 
GET's  with appevent()
i haven´t problems with any key

regards

"Patrick Hanvey" escribió en el mensaje de 
noticias:36af0f20$24cb1f1a$a7348@news.alaska-software.com...

We have several legacy Clipper applications that have been converted to
xBase++, and we are trying to address a problem where users are able to
press Escape to bypass the VALID (postblock).  We found the above
referenced PDR in the KB, but this issue has apparently been open for a
very long time.

We're wondering what others have done to address this issue.  We
considered modifying GetReader in GetSys.prg (possibly to use :Cargo),
but that seemed drastic and we weren't sure how to link the application
to replace the default GetSys.

Any assistance would be appreciated.