[Gambas-user] is it possible to non-virtualize Key.class

BB adamnt42 at gmail.com
Fri Mar 24 12:52:18 CET 2023


On 24/3/23 12:53 pm, Bruce Steers wrote:
>
>
> On Fri, 24 Mar 2023 at 01:57, BB <adamnt42 at gmail.com 
> <mailto:adamnt42 at gmail.com>> wrote:
>
>
>     On 24/3/23 11:59 am, Bruce Steers wrote:
>>
>>
>>     On Thu, 23 Mar 2023 at 22:42, Bruce Steers <bsteers4 at gmail.com
>>     <mailto:bsteers4 at gmail.com>> wrote:
>>
>>
>>
>>         On Thu, 23 Mar 2023, 22:08 Benoit Minisini,
>>         <benoit.minisini at gambas-basic.org
>>         <mailto:benoit.minisini at gambas-basic.org>> wrote:
>>
>>             Le 23/03/2023 à 21:00, Bruce Steers a écrit :
>>             > Could it be possible to non-virtualize Key.class ?
>>             >
>>             > I tried to make a Key.class and added variables for the
>>             properties and a
>>             > way to have it either give the usual Key data or the
>>             set data.
>>             >
>>             > The hope was i could set the variables then trigger a
>>             KeyPress event of
>>             > an object and it could read the fake details.
>>             >
>>             > But it failed with "no Keyboard event data"
>>             >
>>
>>             Yes, there is no way to forge fake input events in GUI
>>             components.
>>
>>             -- 
>>             Benoît Minisini.
>>
>>
>>         That's a shame.
>>         Could there be? 😉
>>
>>         I've been doing it differently by importing the whole
>>         gb.form.edit source and I copied the View_Keypress method of
>>         TextEditor.class and converted it to a MacroKeyPress method
>>         that does not use Key properties only constants.
>>
>>         But it got complicated as I need to follow up the
>>         super.keypress ladder for all .mode files.
>>
>>         Having a non virtual Key.class overriding properties would be
>>         incredibly useful.
>>
>>
>>
>>     Hold the phone...
>>     Actually Copying the KeyPress / OnKeyPress methods and changing
>>     to be MacroPress / OnMacroPress methods has worked surprisingly
>>     well..
>>
>>     downside is i have to have a complete copy of gb.form.editor
>>     source so i'll have to update manually if the main updates.
>>     and the KeyPress/MacroPress and OnKeyPress/OnMacroPress methods
>>     are almost identical code except less a few dots (i changed
>>     properties like Key.Text into KeyText)
>>
>>     upside is I currently have pretty good control of manually faking
>>     TextEditor keyboard presses that I previously recorded.
>>
>>     :D
>>
>>     Overriding Key.class would have been the simplest way.  but i
>>     guess my Key.class file does not get checked first like if I have
>>     a TextEditor.class file it is looked at before the inherited
>>     Super TextEdior.class.
>>     If my custom Key.class file did that maybe it would/could work? 
>>     or is it just bad, ie for security n stuff, just a no no?
>>
>>     I think there could be other usefulness of being able to manually
>>     set the Key.class properties before manually running a method
>>     that expects the virtual Key to exist.
>>
>>     But hopefully what i'm doing right now will be a much better
>>     macro recorder than the x11 version i previously made.
>>
>>     Respects
>>     BruceS
>>
>>
>     I haven't followed this very closely and I am a bit unsure as to
>     what your goals are.
>
>     But could you not use some individual class and set an observer on
>     whatever input controls you are trying to trap (or have I missed
>     the point completely)?
>
>     b
>
>     p.s. I have sometimes got a bit over eager myself and tried to
>     "genericise" things too much.
>
>
> I have the "trapping" as it were , or "recording" as i call it. but 
> then i want to play the keystrokes back in an editor,
>
> the goal is a keystroke recorder.
> something that records the keypresses as you type, and them plays them 
> back in the editor..
> I find it very useful to convert many bits of code,
>
> Typical scenario, there's loads of instances of code in a document 
> that all need adjusting but in a way the Search & replace does not 
> really help...
> So....
> You find the code using the search tool (Ctrl-F)
> then start the keystroke recorder.
> then using backspace/delete, the arrow keys and combinations of 
> shift/ctrl you select/jump words,  edit the bit of code, enter new 
> text, etc,  make it different.
> then you hit F3 to search to the next bit of code.
> then you stop the recorder
>
> then you can play the recorded strokes and the same key events happen 
> on the code then it jumps to the next bit if there is more.
>
> so it's not recording (trapping) then keys i need to do , it's playing 
> them back.
>
> the TextEditor.class code is all there doing the required stuff but 
> uses Key.class so can only be used during actual key presses,
> Seems a waste to have to copy all the Keypress code and adapt it to 
> work without key.class.
>
> That Key.class i originally posted i would have thought would work but 
> like i say the interpreter looks for a valid Virtual Key.class even 
> though i have faked one so it's a dead end. (unless there's something 
> simple Ben can do so my custom Key.class gets seen and accepted before 
> the virtual one)
>
> Respects
> BruceS
>
>
Well then! This is starting to sound very interesting. I can see a few 
uses here.

Firstly, every day "someone" has to go through several text and 
converted pdf to to text files and generally clean them up so we can 
then parse them and update the system database.

Secondly and even more interesting to me is that many years ago I had an 
MSAccess(*) system that was used to script "acceptance testing", in 
other words testing that involved the user view of the target system not 
the developers view. It did something similar but the intent was to get 
the control focus and user input (keyboard or mouse) and then produce a 
text script that was sort of a symbolized version of that interaction. 
IIRC the scripts looked something like:

[Login]
@UserID
!<your name>
@Password
!<bad password>
?

Which meant "On the login screen, in the UserID field enter your name 
then in the Password field enter some garbage. What happens?

It amazed me that genuine user performing these tests could become 
pretty adept at doing these scripts after on a few hours of trying, 
especially when some of them were quite long and intricate.


I tried a long time ago to redo that recorder in Gambas, didn't succeed. 
(it may have been version 1.10 or so)


Also, of course, the gold medal would have been to automate each test 
case, emulating the user interaction and thus save a boatload of time at 
regression testing time. I got some way through that but from memory ran 
into similar-ish problems like how to send a mouse click on a logical 
field, etc. So I am now looking forward to seeing your success in this 
endeavour!

b

* Don't react. It was the early versions of MS-Access, "acquired" but 
not totally screwed by MS. When "Access-Basic" was a good thing, almost OO!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20230324/c62732ce/attachment.htm>


More information about the User mailing list