macOS Cocoa Topics for Carbon Ex-patriots

[GothicChess.Com]

Cocoa / Carbon with #define? Not bloody likely!

....

I mean, really, in 2001 I could understand the appeal of supporting both OS 9 and OS X with one source. But supporting OS 6? Today, in 2007? For fun??! Weird.

I still have MPW Pascal (and C) on my Mac SE/30. It is fun dumping my latest source code projects over to that platform and watching it compile for 2 hours! And the thing will actually run!

I have striven to totally divorce my Operating System dependant calls, such as drawing and event handling, from the rest of my programs, which are in highly portable C.

My chess program runs under every Macintosh ever made (except the latest Mac OS) and, with maybe 3 or 4 #define changes, I can get it to run under WindowsXP, Windows2000, or a Tru64 flavor of Unix.

It's really not THAT hard to do compared to the search engine stuff.

The beauty of it is: The drawing environment/Operating System can change ad infinitum, if I bracket the #defines properly, the thing should be able to run into the "forever future" without too much change.

I can see this will change now with all that NSString stuff...

 

[kainjow]

I don't think you'll have to change too much of your code, if any since it's already portable. It's just the UI that will need to be rewritten in Cocoa (if you want to go that route). And that should be easy to separate from the rest.

 

[GeeYouEye]

I still have MPW Pascal (and C) on my Mac SE/30. It is fun dumping my latest source code projects over to that platform and watching it compile for 2 hours! And the thing will actually run!

I have striven to totally divorce my Operating System dependant calls, such as drawing and event handling, from the rest of my programs, which are in highly portable C.

My chess program runs under every Macintosh ever made (except the latest Mac OS) and, with maybe 3 or 4 #define changes, I can get it to run under WindowsXP, Windows2000, or a Tru64 flavor of Unix.

It's really not THAT hard to do compared to the search engine stuff.

The beauty of it is: The drawing environment/Operating System can change ad infinitum, if I bracket the #defines properly, the thing should be able to run into the "forever future" without too much change.

I can see this will change now with all that NSString stuff...

NSString isn't a mandatory replacement for char *. If all your code is already portable, no reason to make anything but the UI in Cocoa. But to be honest, to an OO Programmer, saving during a solving routine sounds like a horrible layering violation. Even in straight C, I'd keep them in separate functions; you're already mallocing and freeing instead of declaring on the stack so you shouldn't have any trouble passing around a pointer and a length (though even that doesn't matter if you call save from solve, though I'd call both from an enclosing function).

 

[GeeYouEye]

Basically, if you want help going from Carbon to Cocoa, we're happy to help, but C != Carbon.

 

[GothicChess.Com]

Basically, if you want help going from Carbon to Cocoa, we're happy to help, but C != Carbon.

Thanks

Most of the engine is very portable, as you can see the "output" from the database generation run here:

http://www.onlyperfectcheckers.com/databases.txt

Everything is lean C code. If you scroll to the very bottom of that text file, you can see the ASCII diagram of the longest win involving 3 checkers vs. 3 checkers. It takes 161 moves for white to move and win (counting moves for both sides) but the position looks rather docile to the untrained eye:

***********************************************************************************
* 6-piece database, 0 white kings 3 white checkers vs. 0 red kings 3 red checkers *
***********************************************************************************

TOTAL POSITIONS: 7959904
TOTAL BYTES: 7959904

TOTAL WINS   (white to move): 2700665
TOTAL DRAWS  (white to move): 4931025
TOTAL LOSSES (white to move): 328214

Wins resolved as jumps:   2212771
Draws resolved as jumps:  274333
Losses resolved as jumps: 25891

Wins resolved from moving:   487894
Draws resolved from moving:  4656692
Losses resolved from moving: 302323

Wins with NO JUMPS for EITHER SIDE:   425177
Draws with NO JUMPS for EITHER SIDE:  4005208
Losses with NO JUMPS for EITHER SIDE: 130577

Draws resolved from unknowns:  0

Cumulative win length improvements:  19173
Cumulative loss length changes:      4915

Database resolved after 22 iterations
(including 1 jump pass and 1 pass to set unknown positions to draws.)

The longest win requires 161 ply to complete.

There is only one win in this database slice that is that long.
The longest white to move and win position: (white pieces start at top of board)

***************************************************************************************************************
*----------*----------*----------*----------*----------*----------*----------*----------*----------*----------*
*----------*----------*----------*----------*----------*----------*----------*----------*----------*----------*
*----------*----------*----------*----------*----------*----------*----------*----------*----------*----------*
*----------*----------*----------*----------*----------*----------*----------*----------*----------*----------*
*----------*----------*----------*----------*----------*----------*----------*----------*----------*----------*
***************************************************************************************************************
*----------*##########*          *##########*          *##########*          *##########*          *----------*
*----------*##########*          *##########*          *##########*          *##########*          *----------*
*----------*### 32 ###* -------- *### 31 ###* -------- *### 30 ###* -------- *### 29 ###*          *----------*
*----------*##########* |wwwwww| *##########* |wwwwww| *##########* |wwwwww| *##########*          *----------*
*----------*##########* -------- *##########* -------- *##########* -------- *##########*          *----------*
***************************************************************************************************************
*----------*          *##########*          *##########*          *##########*          *##########*----------*
*----------*          *##########*          *##########*          *##########*          *##########*----------*
*----------*          *### 28 ###*          *### 27 ###*          *### 26 ###*          *### 25 ###*----------*
*----------*          *##########*          *##########*          *##########*          *##########*----------*
*----------*          *##########*          *##########*          *##########*          *##########*----------*
***************************************************************************************************************
*----------*##########*          *##########*          *##########*          *##########*          *----------*
*----------*##########*          *##########*          *##########*          *##########*          *----------*
*----------*### 24 ###*          *### 23 ###*          *### 22 ###*          *### 21 ###*          *----------*
*----------*##########*          *##########*          *##########*          *##########*          *----------*
*----------*##########*          *##########*          *##########*          *##########*          *----------*
***************************************************************************************************************
*----------*          *##########*          *##########*          *##########*          *##########*----------*
*----------*          *##########*          *##########*          *##########*          *##########*----------*
*----------*          *### 20 ###* -------- *### 19 ###*          *### 18 ###*          *### 17 ###*----------*
*----------*          *##########* |rrrrrr| *##########*          *##########*          *##########*----------*
*----------*          *##########* -------- *##########*          *##########*          *##########*----------*
***************************************************************************************************************
*----------*##########*          *##########*          *##########*          *##########*          *----------*
*----------*##########*          *##########*          *##########*          *##########*          *----------*
*----------*### 16 ###* -------- *### 15 ###*          *### 14 ###* -------- *### 13 ###*          *----------*
*----------*##########* |rrrrrr| *##########*          *##########* |rrrrrr| *##########*          *----------*
*----------*##########* -------- *##########*          *##########* -------- *##########*          *----------*
***************************************************************************************************************
*----------*          *##########*          *##########*          *##########*          *##########*----------*
*----------*          *##########*          *##########*          *##########*          *##########*----------*
*----------*          *### 12 ###*          *### 11 ###*          *### 10 ###*          *### 09 ###*----------*
*----------*          *##########*          *##########*          *##########*          *##########*----------*
*----------*          *##########*          *##########*          *##########*          *##########*----------*
***************************************************************************************************************
*----------*##########*          *##########*          *##########*          *##########*          *----------*
*----------*##########*          *##########*          *##########*          *##########*          *----------*
*----------*### 08 ###*          *### 07 ###*          *### 06 ###*          *### 05 ###*          *----------*
*----------*##########*          *##########*          *##########*          *##########*          *----------*
*----------*##########*          *##########*          *##########*          *##########*          *----------*
***************************************************************************************************************
*----------*          *##########*          *##########*          *##########*          *##########*----------*
*----------*          *##########*          *##########*          *##########*          *##########*----------*
*----------*          *### 04 ###*          *### 03 ###*          *### 02 ###*          *### 01 ###*----------*
*----------*          *##########*          *##########*          *##########*          *##########*----------*
*----------*          *##########*          *##########*          *##########*          *##########*----------*
***************************************************************************************************************
*----------*----------*----------*----------*----------*----------*----------*----------*----------*----------*
*----------*----------*----------*----------*----------*----------*----------*----------*----------*----------*
*----------*----------*----------*----------*----------*----------*----------*----------*----------*----------*
*----------*----------*----------*----------*----------*----------*----------*----------*----------*----------*
*----------*----------*----------*----------*----------*----------*----------*----------*----------*----------*

I have the code in place to handle the 19 billion 7-piece endings, 111 billion 8-piece endings, just under 2 trillion of the 9-piece endings, and 8.5 trillion of the 10-piece endings.

You can imagine this will make the program unbeatable.

And you can see I have a lot of "coding time" invested in this, so making a Coca app out of it to insure survivability is a high priority for me.

 

[GeeYouEye]

A few months ago there was a series of articles on MacDevCenter.com on how to draw a checkers program in Cocoa. Just hook that up to your backend (though, again, I'd refactor it a bit) and you should be good to go.

 

[cube]

expatriates

 

[GothicChess.Com]

A few months ago there was a series of articles on MacDevCenter.com on how to draw a checkers program in Cocoa. Just hook that up to your backend (though, again, I'd refactor it a bit) and you should be good to go.

Cool, thanks for the tip, I will surely check it out!

 

[GothicChess.Com]

The "keyDown" issue, revisited

Laugh if you will, I was just running my old MacSE/30 version (System 7!) of the checkers program to test it out against the new OS X version (mostly for kicks.)

Then I realized I had the "takeback/replay moves" feature tied into the arrow keys on the old extended keyboard.

Now I realize the "keyDown" event has undergone a major re-thinking in both Carbon and Cocoa, and it is, in fact, quietly discouraged.

What I would like to do:

1. User hits the right arrow key, dispatch to the same menu command as "Replay Next move".

2. User hits the up arrow key, dispatch to the same menu command as "Replay All Moves".

3. User hits the left arrow key, dispatch to the same menu command as "Takeback Previous Move".

4. User hits the down arrow key, dispatch to the same menu command as "Takeback All Moves".

I would like to see how it is done in Carbon C, and Cocoa.

Think of all of the carpal-tunnel you are saving future end users of the program by sparing them constant access to the menus!

 

[Eraserhead]

In Cocoa you should be able to use keyboard keys to control the menus but I can't figure out how you would use arrows...

 

[GothicChess.Com]

It used to be that you could case off of the keyDown event with ASCII constants for the 4 arrow keys, and do whatever based on the handling of it as an event type.

 

[Eraserhead]

It used to be that you could case off of the keyDown event with ASCII constants for the 4 arrow keys, and do whatever based on the handling of it as an event type.

If you can do it in C you can do it in Cocoa, by simply using the C code .

 

[GothicChess.Com]

If you can do it in C you can do it in Cocoa, by simply using the C code .

I understand that amigo, but... the "old way" is going away, and there is some "new way" to do it.

For example, at this post I raised that question:

https://forums.macrumors.com/threads/317190/

... which referenced this tech note...

http://developer.apple.com/qa/qa2005/qa1446.html

..wherein it states:

A modern Mac OS X application should not react to keyboard events but either to commands (when the Command key is down) or to high level Unicode text input, handling the kEventTextInputUnicodeForKeyEvent Carbon Event.

You should not care even if your application is older and still processes keyboard events the old-fashioned way handling the keyDown event.

...which leads to me ask:

"OK, how do you do this now?"

 

[kainjow]

What I would like to do:

1. User hits the right arrow key, dispatch to the same menu command as "Replay Next move".

[...]

So you have a menu item, and you want an arrow key to be the key equivalent for that menu item? Check out this post from the cocoa-dev mailing list. That website (searching the archives) is also very useful for finding out how to do almost anything in Cocoa.

Also, for general arrow key events in an NSView, read here.

 

[GothicChess.Com]

So you have a menu item, and you want an arrow key to be the key equivalent for that menu item? Check out this post from the cocoa-dev mailing list. That website (searching the archives) is also very useful for finding out how to do almost anything in Cocoa.

Also, for general arrow key events in an NSView, read here.

Hi,

Thanks for the links. There is 1 small problem with the solution presented:

(void)keyDown:(NSEvent *)theEvent
{
    NSString  *characters = [theEvent characters];
    int  key = [characters characterAtIndex: 0];

    if (key == NSUpArrowFunctionKey) {
        ;  //  do your up arrow code
    } else if (key == NSDownArrowFunctionKey) {
        ;  //  do your down arrow code
    } else if (key == NSLeftArrowFunctionKey) {
        ;  //  do your left arrow code
    } else if (key == NSRightArrowFunctionKey) {
        ;  //  do your right arrow code
    }

In the Tech Note I furnished in the prior post, we have been advised to stay away from keyDown so intercepting it most likely will not be supported into the "forever future."

Additionally, I am looking for a Carbon example for now, one that I can port to Cocoa with just the "window dressings" changed.

 

[kainjow]

In the Tech Note I furnished in the prior post, we have been advised to stay away from keyDown so intercepting it most likely will not be supported into the "forever future."

That technote is for Carbon. The keyDown: method is from NSResponder, which is 100% supported.

 

[GothicChess.Com]

That technote is for Carbon. The keyDown: method is from NSResponder, which is 100% supported.

Aha! Light bulb moment, thanks