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.

Newcomers DBPro Corner / Custom Input Code Only Working Sometimes?

Author
Message
Mr909
12
Years of Service
User Offline
Joined: 2nd Jun 2012
Location:
Posted: 10th Nov 2012 20:59
Here's the excerpted/modified version of this code I'm running. For some reason, the custom input isn't working correctly, the flag is set, it clears the working string reliably, but it only seems to do the command when it wants to; there is no reliable pattern. I tried removing the SELECT statement but even with if/endif, it seems to be occasional.

Also, I don't want to do INPUT because it makes it so the rest of my output won't show.

Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 11th Nov 2012 00:35 Edited at: 11th Nov 2012 01:23
well your code won't work at all for me. And you should document the code so I know what those keystates are. (its not ascii so I can't look them up easily)

The problem is when you press ENTER it's adding that character to the end. You can't see it, but its there.


This works a lot better for me, but even mine seems to not accept what I type every time. Hmm...




Ok, far as I can tell, when I use LEFT$ to remove the carriage return, it doesn't always do it. Sometimes it takes off the last character. So I'm thinking the carriage return isn't always being added to the string.

Something like this should work:



I think there's a bug in DBP, because I can't seem to make a pattern here. Sometimes the carriage return is there, sometimes it's not. Other times I don't know what it's doing.



Use this example and type "dog" a few times. You'll see the length of the word dog is sometimes 3, 4, or even 5!


Only way around this is to write a custom function to make sure all characters in the string are valid at the ascii-level.

"You're not going crazy. You're going sane in a crazy world!" ~Tick
Virtual Nomad
Moderator
18
Years of Service
User Offline
Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 11th Nov 2012 03:18
Quote: "Only way around this is to write a custom function to make sure all characters in the string are valid at the ascii-level."


works for me (without a hitch):


very curious as to whether or not the code above works on all systems where entry$() behavior may differ.

Virtual Nomad @ California, USA . DBPro V7.7
AMD Phenomâ„¢ X4 9750 Quad-Core @ 2.4 GHz . 8 GB PC2-6400 RAM
ATI Radeon HD 3650 @ 512 MB . Vista Home Premium 64 Bit
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 11th Nov 2012 19:22
That's the more confusing part to me, since I know I've written a custom input routine before using pretty much this same method and it had always worked in the past.

"You're not going crazy. You're going sane in a crazy world!" ~Tick
Mr909
12
Years of Service
User Offline
Joined: 2nd Jun 2012
Location:
Posted: 11th Nov 2012 19:27 Edited at: 11th Nov 2012 19:51
If Phaelax and Virtual Nomad are debating my question, I know it can't be THAT stupid. thanks as always, pals.

EDIT: Actually tested the code thanks a BUNCH, VN. I LOVE IT! I think I might use this in every debug prompt ever.

I implemented a few tweaks, changed it to all-caps instead of all-lowercase, made it so it doesn't ALWAYS show the length, and cleared the buffer a little quicker. Your code works fantastic, but here's a tweaked version for anyone who might pass by this thread.

nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 11th Nov 2012 19:27
Don't forget a true carriage-return is actually 13 + 10 (2 chars) btw... Purely an aside.

Virtual Nomad's approach is almost exactly like mine (I learned the hard way when I started using DBP and once it almost cost me a monitor) except I use all valid inputs from space to tilde.


Quote: "very curious as to whether or not the code above works on all systems where entry$() behavior may differ."

The ENTRY$() function just reads back from the Windows entry-buffer (and sends a clear message if CLEAR ENTRY BUFFER is called), iirc. So it should always work the same (per OS at least) as Windows acts as an intermediary. I have tested Windows 7 (32 & 64 bit) and XP (32 bit) and the behavior is perfectly the same across a few of my past PCs and current laptop.

RP Functions Library v1.0

My signature has not been erased by a mod.
Virtual Nomad
Moderator
18
Years of Service
User Offline
Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 12th Nov 2012 01:05 Edited at: 12th Nov 2012 01:23
so, still thinking about this and expected to be able to sit right down and add proper <delete> functionality in no time.

lo and behold, pressing <delete> on my keyboard returns no ASC value (that i can see/find) when i expected a "127", per the charts.

instead, i have to monitor keystate (211) to add the desired functionality (modified version of the above):



i can live with keystate/scancode "work-arounds" but then i (definitely) return to the "whether or not the code works on all systems" concern.

note: not clearing command$ once a "command" was "executed" was a conscious choice given their natures. so, the <delete> functionality was/is required... which led to this whole other can of worms... :/

also, note how the (rnd/reverse/exit) reference line is printed in-line with the CMD "prompt" at first (until a "valid" key is pressed). odd behavior, to me (then, i've never set cursor and printed at the top of the loop, did some other things, & then went back to print some more, as i have here):


thoughts on either of these bits? again, "work-arounds" exist but i feel i'm "hacking" something i shouldn't have to.

btw, if you're going to play with the code, i already tried removing lower$ which did nothing re: <del>; it was worth a shot

Virtual Nomad @ California, USA . DBPro V7.7
AMD Phenomâ„¢ X4 9750 Quad-Core @ 2.4 GHz . 8 GB PC2-6400 RAM
ATI Radeon HD 3650 @ 512 MB . Vista Home Premium 64 Bit

Attachments

Login to view attachments
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 12th Nov 2012 19:42
Use the optional parameter: entry$(1)
That will automatically handle the delete key for you.

Your code works for me, but mine still gives funky results. What kind of stupid typo in my code do I have that's driving me nuts?!

"You're not going crazy. You're going sane in a crazy world!" ~Tick
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 13th Nov 2012 11:59
Quote: "Use the optional parameter: entry$(1)
That will automatically handle the delete key for you."

It only handles Backspace for me so this was my solution:

^ Excuse any typos. May make a decent version of this for a sometime...


Quote: "
Your code works for me, but mine still gives funky results. What kind of stupid typo in my code do I have that's driving me nuts?!"


The pressing of Return lasts longer than the call to CLEAR ENTRY BUFFER - basically, it clears and then receives return again so you'll alwaysget an extra char or two after the initial input.

Try changing this section like so:


RP Functions Library v1.0

My signature has not been erased by a mod.
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 13th Nov 2012 20:12
Quote: "It only handles Backspace for me so this was my solution:"

My mistake, you did say delete but I was thinking backspace.


Gotcha, that makes sense.

"You're not going crazy. You're going sane in a crazy world!" ~Tick

Login to post a reply

Server time is: 2024-11-21 18:28:05
Your offset time is: 2024-11-21 18:28:05