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?
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.
Are you using the latest version ?
10.283.
Is this something that was addressed in a recent beta update?
EDIT: I have additional information on recreating the problem. See new post a few below this one...
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.
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.
Okay, we discovered that this problem exists
regardless of the input method used! For example, try this code:
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 DOWNThis 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.
Quite interesting. :o
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?
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...
Compiling to universal as well as x86 reports same errors?
Yep, locks up exactly the same when compiled to either x86 or Uni.
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.
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?
Quote from: erico on 2012-Jul-07
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. :)
Quote from: Ian Price on 2012-Jul-07
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?
Hmm...I use a wireless keyboard with my Mac mini, but the cursor keys seem to work fine & are responsive. (Until the lock-up, of course...)
I never stated that the keyboard doesn't work fine with my Mac Mini - the cursors don't work properly with TouchPad with GLB apps. All other keys work fine, but not the cursors.
I suspect that there may a disparity between GLB and the key values that the cursor keys produce for Mac. On TouchPad the values returned for the cursors are not the 200, 203,205 and 208 (or whatever) as expected on Windows and others systems - IIRC the values returned are higher than 255. But this may be a TP problem and nothing to do with the Mac keyboard at all (in fact I tried to buy a proper HP TP keyboard for this very reason - HP accepted the order, took my money then cancelled a couple of weeks later, stating that they were out of stock :()
Dunno.
Quote from: Ian Price on 2012-Jul-08
I never stated that the keyboard doesn't work fine with my Mac Mini - the cursors don't work properly with TouchPad with GLB apps. All other keys work fine, but not the cursors.
Apologies, I misunderstood. I'm not familiar with what a Touchpad is (I'm primarily a PC guy), so I assumed it was a specific type of Mac, not a peripheral. ;/
The TouchPad is an iPad like tablet from HP (Hewlett Packard). It allows BT tethering/pairing of keyboards and HIDs but the Apple keyboard one gave strange results (as I mentioned). I should have made my original post a bit clearer :)
you can get key-codes > 255 on a mac? That might be an error.
Gernot,
Any thoughts about the lockup part? This seems to be a pretty critical issue...based upon my tests, it appears that any GLB program compiled for Mac can lock up if the user presses the wrong keys. And it happens regardless of whether the GLB program actually looks for keypresses or not!
Hi - just been revisiting this thread after 6 months.
Well glad I wasn't going mad! lol
For what its worth I went away in a cottage for a week and was writing my game on a MacBook which kept locking up when scanning for cursor keys - I was also checking for the Enter key as well.
The lockup required a force quit - if I was able to move focus and manage to do it - a few times I just had to hit reset.
I can confirm that it was later testing on my iMac that made this issue re-occur and I removed the cursor checks - my game to my knowledge does not lock up now and I still check for the Enter key.
So I had the problem on two different MACS. It has never done this on the MACS when I boot them into Windows 7 natively using BootCamp.
I will test the interesting test program earlier in this thread and report back my results. Latest non beta version here as always.
I am running the GM Seed of Mountain Lion here so can test on that - Lion had its share of obscure bugs - anyone get this problem on Snow Leapord? Just a thought...
ML seems very stable and for the first time since running Lion, this particular iMac now wakes from SLEEP mode every day which is a huge timesaver for me!
later...
I wonder if it has anything to actually do with the keyboard, would that be the same if on a PC hackintosh?
I spending the week at my folks place, where my old lap has a partition with osx 10.69 hackintosh style, I wonder if it will behave the same, will give a test later today.
ok tested on a hackintosh, produces the same behaviour, crash with a tum sound.
So it must be the way the osx deals with the keyboard I guess. :sick:
Today I have seen this bug happens to here and just suddently hang. I guess its the extractly same bug (ENTER ENTER ENTER UP DOWN hang it).
Here its on a Apple MiniMac from last year using lasets Lion with a Apple keyboard and lastest v10 (not checked with early v11 beta). Also this is not a hackingtosh, but can also happens on the real gear.
So its a confirmed bug and hope its got fixed in v11.
Hmm... Good thing I used WASD. Weird bug though,
yep, pretty weird bug, happened on at least 3 different macs from my friends too.
It could be bad for you if you are using the arrows+enter or your main menu for example. :noggin: