Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / INKEY$() retaining value

Author
Message
BatVink
Moderator
23
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 18th Jun 2011 12:15
I have a weird situation which I haven't encountered before, despite using this method many times.

This code waits for a key to be pressed before continuing...



but in my latest code, the value of inkey$() is retained when I return to this part of the process. in between it has performed masses of other processes (but not keyboard related) and yet inkey$ is still what was pressed 10 seconds or more prior.

Any ideas?

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 18th Jun 2011 12:49 Edited at: 18th Jun 2011 13:04
I never know what some of these commands do, i.e. things like clear entry buffer and flush video memory. They never seem to do anything when I try to use them.

Does inkey$() need a sync before it's updated? If so then your while loop could be skipped before the code hits the necessary sync.

I'm guessing though.

Edit

Looks like I was guessing wrong.

I can't reproduce your problem. Can you provide a short snippet that behaves like that?
Hodgey
16
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 18th Jun 2011 13:03 Edited at: 18th Jun 2011 13:03
What if you change inkey$() to the entry$() command, does it work then?

A clever person solves a problem, a wise person avoids it - Albert Einstein
BatVink
Moderator
23
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 18th Jun 2011 13:53
Thanks for trying/advising on this one.

Quote: "Can you provide a short snippet that behaves like that?"

The odd thing is, I've used this method for years. It's only today after adding code as described above that it has failed. The same technique is elsewhere in the program successfully. For example, my keyboard for entering high scores uses it extensively, and it's fine. So in short, if I provided the code as a standalone snippet it would work.

Quote: "What if you change inkey$() to the entry$() command, does it work then?"

Good idea, I should use this. The CLEAR ENTRY BUFFER is clearing this before the loop so it should be fine.

It would still be nice to know what's going on. I can only put it down to the use of some other code that is corrupting it, most probably a plugin.

Hodgey
16
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 18th Jun 2011 14:21
Quote: "Good idea"

Thank you

The only other thing I can think of is changing it to a repeat loop. Like this:

So now atleast 1 sync call is made before the condition is checked which means that whatever is causing the problem may get updated and cease to be problematic. Just theory but may work

A clever person solves a problem, a wise person avoids it - Albert Einstein
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 18th Jun 2011 14:26
Yes, I'd vote for that too - unless you really don't want the loop executed at all. Perhaps just stick an extra sync before the loop?
BatVink
Moderator
23
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 18th Jun 2011 19:07
SYNC is a good thought, but in this case definitely not the problem. There will have been hundreds of Syncs between the pressing of the key and the next check of the value. The scenario is...

+ check for keypress
+ find keypress and exit loop
+ do *LOTS* of other things
+ check for keypress
+ old value still retained, loop immediately exits

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 18th Jun 2011 22:32
Have you tested this on other machines or keyboards? What would happen if the key in question tended to stick?
BatVink
Moderator
23
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 18th Jun 2011 23:28
Quote: "What would happen if the key in question tended to stick?"


Thinking outside the 4-sided rhombus, I see
I tried different keys because I convinced myself the value it retained was coincidentally the same one I had pressed. I found myself irrationally trying to find a key that would exhibit a different behaviour. If you're interested I decided that key was 'y', which in itself is irrational if you look into the concept of anchoring.

So it's official, programming can actually make you insane.

Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 19th Jun 2011 00:03 Edited at: 19th Jun 2011 00:06
CLEAR ENTRY BUFFER only works for ENTRY$(). INKEY$() should show nothing at all the moment the key is let go.

The following gets INKEY$() and ENTRY$() at the same time and waits for 10 seconds before showing the results... INKEY$() should be empty while A$ should show the last key pressed using INKEY$(). ENTRY$() keeps all keys pressed until CLEAR ENTRY BUFFER is seen (in this press the spacebar to clear the buffer).



If you want that code within the WHILE/ENDWHILE to run at least once use (as Hodgey suggested) a REPEAT/UNTIL instead. The difference between our methods is I prefer to use SCANCODE() to check if a key has been pressed (or not).

Run at least once even if a key is pressed:


May or may not run depending on if a key is being pressed already:


Edit:
Quote: "So it's official, programming can actually make you insane."


I agree 100%... especially when trying to find a bug that likes to hide under code rocks.

Rich Dersheimer
AGK Developer
17
Years of Service
User Offline
Joined: 1st Jul 2009
Location: Inside the box
Posted: 19th Jun 2011 00:03
I recall having similar problems, so whenever I use that kind of a loop, I do this...



...which seems to work okay.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 19th Jun 2011 00:50
Unless you don't want the loop to run at all in certain circumstances.

Quote: "So it's official, programming can actually make you insane."


I believe the latter is a prerequisite.

Don't you just love bugs that only manifest themselves if you have an inordinately large batch of code to check.
Hodgey
16
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 19th Jun 2011 01:52
Quote: "Thinking outside the 4-sided rhombus, I see"

So uhhh... what does a 5 sided rhomus look like?

Quote: "Quote: "So it's official, programming can actually make you insane."

I believe the latter is a prerequisite"

I believe I'm perfectly sane, now where's that severed human hand I had lying around...

Quote: "Don't you just love bugs that only manifest themselves if you have an inordinately large batch of code to check."

Don't get me started, but they are the most satisfying to solve

A clever person solves a problem, a wise person avoids it - Albert Einstein
BatVink
Moderator
23
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 20th Jun 2011 00:31
I appreciate the comments on the loop thing, but I can assure you that no key is pressed on entry to the loop. Repeat or While is academic really, there is no key press going on.

I think I have to chalk this one up to some interfering code in a plugin somewhere. I've replaced it with a mouse click, which actually works better in the circumstances.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 20th Jun 2011 12:46
Have you tried printing the value of inkey$() at that point? For example, is it actually the key that was last pressed or detected or is it something else? If the latter then something is interfering with something somewhere - or you may have encountered DBPro's first bug ...
BatVink
Moderator
23
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 20th Jun 2011 13:37
Quote: "Have you tried printing the value of inkey$() at that point? "


Yes, I did that to a Console window so I could watch it as it happened. It's definitely retaining a value that was pressed 10 seconds and 600 SYNCs ago.

Quote: "you may have encountered DBPro's first bug ..."

Gosh, I hope we haven't unveiled the possibility that there may allegedly be a bug in DBPro

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 20th Jun 2011 13:45
Sounds like a question for IanM. I wonder what, precisely, clears inkey$() behind the scenes and what triggers it? Could the "trigger" or whatever it is have been turned off somehow elsewhere in the code or in a plugin perhaps?

You might have answered this already but I'll ask anyway: do you get the same symptoms on other machines?
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 20th Jun 2011 13:58
I prefer to use



TheComet

BatVink
Moderator
23
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 20th Jun 2011 15:31
Quote: "do you get the same symptoms on other machines?"


I never tried. I should have tried it, the code has been changed now. Once the newsletter is done and I have more time, I'll try again on another machine and see what happens.

IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 20th Jun 2011 19:02 Edited at: 20th Jun 2011 19:03
Quote: "Sounds like a question for IanM."

Why oh why do you always volunteer me for this kind of thing?

Ok, I have no definite idea why this is happening as the code is very clear on what happens:
- The key value is recorded when the windows message loop (usually executed as a part of SYNC) processes a WM_CHAR message (which as you'll be surprised to hear, contains the character pressed).
- The key value is cleared when a WM_KEYUP message is received.
- The INKEY$ function simply constructs a string containing that single character value and does no other processing of its own.

So something must be happening that causes the WM_KEYUP message to not be received by the DBPro window - that would usually be caused by loss of focus, and as BatVink has just admitted that he's using my console commands, that may be the cause.

It could also be caused another plug-in that intercepts the windows messages (eg Blue GUI), but he hasn't owned up to that yet!

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 20th Jun 2011 19:33
Quote: "Why oh why do you always volunteer me for this kind of thing?"


Sorry! Habit I suppose - and your name is quicker to type than most.

Quote: "but he hasn't owned up to that yet!"


Indeed he hasn't.
BatVink
Moderator
23
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 20th Jun 2011 21:44
Quote: "It could also be caused another plug-in that intercepts the windows messages (eg Blue GUI), but he hasn't owned up to that yet!"


mmm...I am using the Blue Gui webcontainer. Here's the gist...

1. Create menu page with webcontainer
2. Click on menu option, delete webcontainer, display "How To" page.
3. Press a key, delete "How To" page, show menu screen, create webcontainer
4. Click on menu option, delete webcontainer, show "How to"
5. ROGUE KEY PRESS DETECTED HERE, "How To" immediately deleted and back to menu.

so maybe the webcontainer is created while key is still pressed and steals the KEY UP.

That sounds quite plausible to me, thanks Ian

Note to self: don't leave out the detail when reporting issues (just like my complaints about my own customers!)

DVader
22
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 20th Jun 2011 21:56
I have read a fair bit of this thread and can't put my finger on the problem.



That code should clear the entry buffer , and wait until you press a key.
I think the problem must be related to the `lots of stuff` you mention.

Heres a couple of points I will note.
1. "Clear entry buffer" will not affect the value of inkey$ and is unneeded with your supplied code (of course it may be needed dependent on the rest of the code.).
2. "Inkey$" detects one key press only and should revert to 0 on the next loop of your program, if the key is released.

So I am not sure what the problem is exactly. Everyone else seems to know what it is, but I am in the dark. I have played around a fair bit with strings and such in DB, with various projects I have done, so I am sure I could help. If it is simply a key repeat problem I am sure it will be easy enough to squash it.
I read you have worked round it, but I am sure you would prefer to work through it if possible

@GreenGandalf, you surprise me, but you obviously have more interest in shaders than text input lol. Shaders are far more sexy Clear entry buffer does what it says on the tin. You simply have to use the entry$ command, rather than input for instance. Here is a quick example.




You will see it does work Indeed, it is the only way to do text entry, in standard DB, IMO.

Anyway more info needed to solve this, whatever it is exactly!!

http://s6.bitefight.org/c.php?uid=103081

Login to post a reply

Server time is: 2026-07-11 02:14:06
Your offset time is: 2026-07-11 02:14:06