Recent

Author Topic: Trap control characters without UI  (Read 3158 times)

jbmckim

  • Full Member
  • ***
  • Posts: 144
Trap control characters without UI
« on: March 07, 2019, 09:19:38 pm »
I have a standalone class that talks to a remote digital controller.  I write to the controller and then wait for a response.  Sometimes things can go wrong and therefore I'd like the use to be able to Cntrl-x (or other) out of the waiting process.  The kicker:  there's no UI associated with this process so event handling like OnKeyPress etc. is not available.  Here's the loop:

Code: Pascal  [Select][+][-]
  1.  repeat
  2.  
  3.     ReadPort(iReadPort,bReadPortTrue);
  4.     bDone := bReadPortTrue;
  5.  
  6.     until (bDone = true);      

I'd like to add something that would allow me to set bDone to true in the case of the user issuing a break command from the keyboard.

Sorry in advance if this is a case of weak Google skills but I tried a few different searches and found nothing.

Thanks in advance.


Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: Trap control characters without UI
« Reply #1 on: March 08, 2019, 04:24:29 pm »
Code: Pascal  [Select][+][-]
  1.  repeat
  2.  
  3.     ReadPort(iReadPort,bReadPortTrue);
  4.     bDone := bReadPortTrue;
  5.  
  6.     until (bDone = true);      

No solution but 2 remarks on the code.
  • if bReadPortTrue has no side effects (i guess it's a variable) then it makes no sense to assign it to dDone and then use bDone in the until part
  • Comparing a Boolean to True (or False) makes no sense at all. If it did, then you would also have to compare the Boolean (bDone=True) to True, ad infinitum. It just hurts the eyes, and it does not make for better readability.

Bart

jbmckim

  • Full Member
  • ***
  • Posts: 144
Re: Trap control characters without UI
« Reply #2 on: March 08, 2019, 07:01:53 pm »
ReadPort is a boolean function.  The return is not interrogated here because a 'false' result (most likely catastrophic) is already handled in the lower level ReadPort.  bReadPort is passed by reference and indicates whether the DIO controller has received port high voltage from the sending device.

Still looking for suggestions/ideas.  I've started looking at opening the keyboard as an input file and interrogating input.  However, I'd very much like to keep this as simple as possible and that starts to turn into quite a bit of code (comparitively) rather quickly.  (I've already talked to this device in VB.Net and C# and the possibility of writing too much code for too little benefit is a strong memory.)

jbmckim

  • Full Member
  • ***
  • Posts: 144
Re: Trap control characters without UI
« Reply #3 on: March 20, 2019, 01:32:24 am »
Nobody huh...well...that was disappointing.

jamie

  • Hero Member
  • *****
  • Posts: 6090
Re: Trap control characters without UI
« Reply #4 on: March 20, 2019, 01:43:38 am »
Don't know the OS..

Anyways..

GetKeyState(Specify_the_VKey_To_Check);

do that twice, one for the CONTROL and the other for the X.

Just a thought really,....
P.S.
 It needs Windows unit or LCLIntf I think.
The only true wisdom is knowing you know nothing

Cyrax

  • Hero Member
  • *****
  • Posts: 836
Re: Trap control characters without UI
« Reply #5 on: March 20, 2019, 06:31:23 am »

Zvoni

  • Hero Member
  • *****
  • Posts: 2319
Re: Trap control characters without UI
« Reply #6 on: March 20, 2019, 08:22:51 am »
Don't know the OS..

Anyways..

GetKeyState(Specify_the_VKey_To_Check);

do that twice, one for the CONTROL and the other for the X.

Just a thought really,....
P.S.
 It needs Windows unit or LCLIntf I think.

Shouldn't that be "GetAsyncKeyState"?
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

jbmckim

  • Full Member
  • ***
  • Posts: 144
Re: Trap control characters without UI
« Reply #7 on: March 20, 2019, 05:50:52 pm »
Thanks for the response

This is a windows app. (Good point.)

I have added keyboard and attempted GetKeyState but with only one call.  Didn't evidence any fetch keyboard activity that I could trap.  Obviously could be pilot error but I was wondering if the GKS interrupt would be masked by the form that calls the object in which this looping behavior is hosted.

Haven't tried GetAsyncKeyState.  Does that allow my loop processing to continue and then break to an interrupt vector if the user actually presses something?


jamie

  • Hero Member
  • *****
  • Posts: 6090
Re: Trap control characters without UI
« Reply #8 on: March 20, 2019, 10:21:20 pm »
I forgot you were in CONSOLE mode or no visual mode at all...

the GetKeyState reads from the Message que...

Use the GetAsyncKeyState instead.

you need to do some testing to indicate what is happening however.

 If the return value < 0 then key is currently being held down.
 
 if the return value AND with 1 is not 0 then the key was pressed before you made this call.

 If another Thread is calling this function, it will return 0.
The only true wisdom is knowing you know nothing

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: Trap control characters without UI
« Reply #9 on: March 20, 2019, 10:51:10 pm »
This is a windows app. (Good point.)
One solution that comes to mind would go like this:

1. before you enter the loop that reads the port, create/open a named file mapping.
2. set the first byte in the file mapping to a value that indicates "continue" looping.
3. poll that value in the loop, if it isn't the "continue" value then break out of the loop.

the second step is to create a simple - and completely independent - console application that opens the named file mapping (of course, the name has to match) and overwrites the "continue" value found in the mapping.

It only takes a few lines of code to implement that. 

HTH.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

 

TinyPortal © 2005-2018