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 / Inkey$() and Keystate(#) does not work within my subroutine

Author
Message
Katyman
FPSC Reloaded TGC Backer
12
Years of Service
User Offline
Joined: 5th Oct 2012
Location: Katy, Texas USA
Posted: 28th Aug 2015 23:05
Link
Hello friends!

Got me a bit of a snag here that is making me turn blue.

I have a small bit of code that if ran alone works excellent!!'

Rem ***** Main Source File *****
Wizard:

Print "You Drew A Monster Card"

do
cls
print "Wizard, please choose (A)ttack,(F)ireball, or (L)ighting Bolt"
if Keystate(30)=1 then Zap$ = "A" : exit
if Keystate(33)=1 then Zap$ = "F" : exit
if Keystate(38)=1 then Zap$ = "L" : exit
sync
loop
exit

When A,F, or L is pressed then the program exits...simple.

HOWEVER

When I place the same bit of code within my program as a simple subroutine (add return on the end of course) then the code REQUIRES that the RETURN KEY be pressed after the letter for the routine to continue, but because RETURN was pressed, then the Returnkey() now equals "1" and it throws off the rest of the routine waiting for the RETURN key to be pressed and exits back to the Main program.

I tried both Inkey$() and now trying Keystate$() and as I said they work without pressing the RETURN key if I run it just by itself on a blank new DBP page.

When old programmers die...do they decompile?
Back to top
Profile PM Email
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 29th Aug 2015 02:43
Link
Exit will exit a loop. End will end the app.
Back to top
Profile PM Email
Katyman
FPSC Reloaded TGC Backer
12
Years of Service
User Offline
Joined: 5th Oct 2012
Location: Katy, Texas USA
Posted: 29th Aug 2015 11:34
Link
That I am aware of, What I don't understand is why Inkey$() or Keystate() requires me to press RETURN in my program but not if I open a new project and just run that little code alone. If I run it stand-alone and press A,F, or L then the program ends. Any other key will not exit the loop.

But within my main program as a subroutine, I press A,F, or L but it sits there until I press RETURN, which I should not need to do.

Is there a way to remove the RETURN keystate of "1" before the program reaches the RETURNKEY() command? Or some way to fix the code so that I do not have to press RETURN each time the subroutine is called?

Thank you!!



When old programmers die...do they decompile?
Back to top
Profile PM Email
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 29th Aug 2015 19:42
Link
From the code you have posted, I really can't say what the problem could be. The Inkey$() and Keystate() functions do not require you to press return, whether in a subroutine, function or stand alone. Please supply a complete short snippet demonstrating the problem.
Back to top
Profile PM Email
Katyman
FPSC Reloaded TGC Backer
12
Years of Service
User Offline
Joined: 5th Oct 2012
Location: Katy, Texas USA
Posted: 29th Aug 2015 20:28
Link
That Snippet is the actual subroutine from the game that sync's with the graphics. I mean, really? It does not make any sense at all that I have to press RETURN to accept the key press. Like putting a match to gasoline and it DOESN'T ignite.

Interesting thing is a have another INKEY$() routine just like this (before I tried Keystate() on this one), and I have no problems at all. I copied it basically word for word to the subroutine but the subroutine requires that I hit RETURN now. My code is 8000+ lines long so it would be difficult to paste any snippet other than this subroutine that won't work for what unknown reason. I may have to do a rewrite just for this few lines of code. Going to take a nap first and think this over.

Meanwhile, is there maybe a way I can adapt this to circumvent my problem



When old programmers die...do they decompile?
Back to top
Profile PM Email
Katyman
FPSC Reloaded TGC Backer
12
Years of Service
User Offline
Joined: 5th Oct 2012
Location: Katy, Texas USA
Posted: 29th Aug 2015 20:35
Link
I am listing this where the subroutine is called.


It is called from a SELECT command within the Main Game FUNCTION but try as I have, the DB Commands INKEY$() and Keystate() are not working like they should and require that stubborn RETURN key stroke.

When old programmers die...do they decompile?
Back to top
Profile PM Email
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 30th Aug 2015 03:23
Link
I would suggest doing a While Zap$ = "" : EndWhile instead of a Do:Loop

Back to top
Profile PM
Katyman
FPSC Reloaded TGC Backer
12
Years of Service
User Offline
Joined: 5th Oct 2012
Location: Katy, Texas USA
Posted: 30th Aug 2015 03:33
Link
I will let you know, thanks

When old programmers die...do they decompile?
Back to top
Profile PM Email
Katyman
FPSC Reloaded TGC Backer
12
Years of Service
User Offline
Joined: 5th Oct 2012
Location: Katy, Texas USA
Posted: 31st Aug 2015 04:28 Edited at: 31st Aug 2015 04:30
Link
Hello again!

Well I did as you requested and it did not work. So I tried something else. I changed the Returnkey() to MouseClick()=2 for right click. The idea was that when I was forced to press Return then instead of Returnkey() coming back as a 1, the MouseClick() would be required.

That was the plan. But an interesting situation developed.
When the player is asked for (A)(F) or (L), the Return key was always required to continue on. BUT NOW the Right Mouse button is required thus I am back at square one. Somehow the subroutine and a function are linked together in some strange fashion. The subroutine is called first and the function is called much later, but not within the subroutine; they are very much separate enities. The only argument the subroutine creates is ZAP$ for the selection. Only thing I can think of is an old bug from DOS BASIC days whereas the first three characters of a label must be unique throughout the program so WIZ1 and WIZ2 conflict but 1WIZ and 2WIZ do not. Wonder if that is true in DBPro? I will change the Function and subroutine names to see.

My only other option is to uninstall and reinstall DBPro in case of a glitch. HAs anyone heard of such a bug where two different items get linked like that? I will tell you my results.

When old programmers die...do they decompile?
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-11-23 15:14:22
Your offset time is: 2024-11-23 15:14:22