Messages

Ah cool, I'll try that.  Thanks, spacefractal!

Is there a way for GLBasic to distinguish between 1st & 2nd generation iPads?  The screen resolution is the same, and PLATFORMINFO/DEVICE is supposed to give "IPAD" for both.

I ask, because the iPad 2 has twice the memory.  My current program runs fine on the 2, but runs out of memory on the 1.

I can tone down some of my graphics to let it run on the iPad 1, but I'd really like to keep the big animations on the iPad 2 for that extra polish.

For my two cents, I wouldn't mind paying for an upgrade to 11 either.

In addition to supporting Gernot in general, it would make me feel less guilty about making feature requests.

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!

[TouchPad]

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. 

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...)

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. 

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

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...

[regardless of the input method used!]

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.

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.

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

10.283.

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

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.

Hmm...if the problem is technically fixed & it's just waiting to be implemented in an upcoming build, I'll wait for that.    Thanks!