Long term Mac Cursor Key problem.. ?

[mrplant]

Hi. I know this is a strange one. but I have been writing a game since October. Back then I was checking for keys I and P to move left and right as well as Q and Z to move my man up and down.
I was also checking for the cursor keys as well.
My code was like this:

IF KEY(200) OR KEY(16) etc..

This was in a tight game loop and I made my code  able to compile for Windows and Mac.

To cut the story short and get to the point here..

During game testing, my game would randomly lock up totally the MAC when moving around - there was no warning it just sometimes happened.
This was only on the MAC code - windows code never had this problem despite running the same code.

My solution after a week of mucking around was to remove support for the cursor keys and just keep I P Q and Z.
Longterm testing has never once gave me a lockup since then.

I have a main game menu that allows you to select game modes from. Only recently having completed the game and therefore spending more time using this menu, has it reared its ugly head again.
My Mac has now hard locked up on that menu twice now in the past fortnight. Once last night.
the windows version never does this.

Again, I combed my code line by line. Nothing Mac specific again but I did notice something that I had overlooked since October. During the main menu I am still checking for I P Q and Z and also the cursor keys.

so...

Has anyone else out there had a problem with the Mac hard locking up - whilst scanning for the cursor keys?
Could this be a GLBasic bug?

[BasicMe]

Apologies for digging up a 6-month-old topic, but it sounds like I'm having the same issue.  My program will sometimes lock up when using the cursor keys on the Mac, even though the exact same code doesn't lock it up on Windows.  Like Mrplant, there is nothing Mac-specific about the section of code in question.

After a lot of trial-and-error, I've also discovered the following:

The cursor-down key seems to be the one causing the lock-up most reliably.  Sometimes pressing cursor-down does what my code intends it to do, but other times it locks up instead, requiring me to force-quit.  It's most likely to happen if I've pressed the ENTER key recently, even when I've commented out all functionality that would result from hitting ENTER!

If anyone can shed additional light on this, I'd be grateful.  Since my program requires typing & maneuvering through large blocks of text, Mrplant's solution of using letters instead of the cursor keys isn't a good solution for me.

[MrTAToad]

Are you using the latest version ?

[BasicMe]

10.283.

Is this something that was addressed in a recent beta update?

[BasicMe]

EDIT: I have additional information on recreating the problem.  See new post a few below this one...

[Ian Price]

Does Mac have "Sticky keys" like Windows (Press SHIFT multiple times)? Maybe you are triggering it with your combo unknowingly or it's turned on somehow.

Have a look here - http://mactips.info/2010/04/sticky-keys-can-be-very-handy

Useful info here too - http://heresthethingblog.com/2012/01/13/enable-sticky-keys-pc-mac/ 

Don;t know if this causes your problem, but it won't hurt to have a look.

[BasicMe]

Hi Ian,

Good thought, I appreciate the suggestion. But I just confirmed that the sticky key option was/is turned off.

For what it's worth, I've confirmed the issue is present on both Macs that I have access to.  One is a Macbook, the other a Mac mini bought last year; both are Intel.

EDIT: Oh, and to clarify: I know that sticky keys can be enabled on the PC by tapping a key rapidly several times in a row.  But in this case on the Mac, the keys don't have to be tapped rapidly to cause the lockup.  You can run that code, hit ENTER - ENTER - ENTER - CURSOR UP - CURSOR DOWN with several seconds inbetween each keypress, and it will still lock up.

[BasicMe]

Okay, we discovered that this problem exists regardless of the input method used! For example, try this code:

Code (glbasic) Select Expand


loop:
FOR g=0 TO 5
PRINT "NEW TEST "+g, g*100, 80
SHOWSCREEN
NEXT
GOTO loop


On Windows, it will run indefinitely until you hit ESC, regardless of what other keys are pressed.

On an Intel Mac, type the following keys in order:
   ENTER
   ENTER
   ENTER
   CURSOR UP
   CURSOR DOWN

This will consistently lock up the program! And it does so even though the code uses no GLBasic commands to actually poll Mac key presses!

While this is the most consistent way to get the program to lock up, there are other ways that can do it as well.  The consistent elements to all lock-ups seem to be the following:

• ENTER must be pressed;
• CURSOR UP must be pressed sometime after pressing ENTER;
• CURSOR DOWN must be the next key pressed immediately after CURSOR UP.

It's almost as if there's a built-in easter egg in GLBasic, but one that results in a lock-up.   

I would love for someone else to test this on their own Mac.  Because otherwise, based on our own multi-Mac testing, this is looking like a critical bug that could affect any Intel Mac program compiled from the current version of GLBasic.  Particularly those that encourage a user to use the keyboard.

[erico]

Quite interesting.

I had a hackintosh around, but it is at my folks place.
I will take time to test such on my friend´s Macs and let us know.
What mac osx are you running?

[BasicMe]

Ah, good question!  The Mac Mini is definitely Lion, and I believe the Macbook is as well.  Hmm...now you've got me really curious to locate a pre-Lion machine to test on...

[erico]

Compiling to universal as well as x86 reports same errors?

[BasicMe]

Yep, locks up exactly the same when compiled to either x86 or Uni.

[erico]

As soon as down is pressed, it hangs, and won´t come back, like you said.

Could it be it understands the app is paused? or out of focus?

That was on a OSX 10.68.

[Ian Price]

I just remembered - my Mac wireless BT keyboard cursors keys show very odd numerals when paired with my Touchpad and are non-responsive. I wonder if that's part of the problem?

[BasicMe]

As soon as down is pressed, it hangs, and won´t come back, like you said.

Could it be it understands the app is paused? or out of focus?

That was on a OSX 10.68.

Erico, thanks for testing this!  It's good to know it's not something being caused by, say, a corrupt install of GLBasic on my end!

I think it's safe to say it's a widespread problem.  It's certainly possible that it's an errant pausing issue.  Moving the mouse cursor out of the app window on the Mac causes it to temporarily pause, something that doesn't happen in Windows, so this could possibly be related.

In any case, it does appear that some sort of caching on GLBasic's part is going on, since it requires certain keys to be pressed in a combination (e.g. CURSOR UP immediately before CURSOR DOWN).  I'm hopeful this knowledge can help Gernot track it down easily.