macOS Converting Windows program to Mac

Assuming:

1) You are using Cocoa, not Carbon (which is recommended)
2) You are using the standard NSTextView, not some alternative of your own devising

then the documentation contains the answers

You haven't stated whether you'll be using Carbon or Cocoa. Carbon will look similar and easy since it's a C-based API just like Win32, but in the long run it isn't worth it since it's virtually being deprecated by Apple.

I'd suggest Cocoa, which may be a bit tough initially since you'll have to learn Objective-C, but it's pretty easy once you get going.

NSTextView (which is the main control for handling large amounts of text input) contains a method called characterIndexForInsertionAtPoint, which takes a single argument of type NSPoint, which you can be used with [NSEvent mouseLocation]. Once you have the character index, you can then use normal NSString methods and determine the line number and character index for that line.

Edit: robbieduncan beat me to it

resander said:

Many thanks for your advice.

The programs I am converting are written in procedural (non-OO) C++
without using MFC or NET frameworks. There are about 100 dialogs many of them non-trivial, i.e. values of certain fields determine the value sets and
mode of display of other fields. There are about 150 source files, so
at least by my standards the programs are quite large.

I also need to continue to support the programs on Windows.

I think I have two choices:

1. totally rewrite the GUI using Cocoa or Carbon for Mac and keep the
Windows programs without changes. Drawback:
two GUIs to support for the remaining lifetime of the
programs.

2. the algorithmic stuff (ca 25%) should translate without any changes.
The problem area is handling the GUI events which is different
under Windows. I have looked at Carbon and (think I) can see how to
rewrite the GUI on Windows to use and installl event handlers the way
it is done on Mac. End result: only one GUI to look after.
For this choice I could not use Cocoa for the GUI.

Not sure which alternative is best OR if there are better ways.
Advice welcome.

Click to expand...

You could always port the GUI to use Qt or something similar and just have one GUI architecture for Mac OS X, Windows and Linux for free rather than having a Cocoa or Carbon Mac version and a win32 Windows version. Qt is just one example that you could use, there are many more cross platform GUI libraries.

Hi resander,

I've converted a lot of code from Windows (Win32) to Mac OS. Despite Carbon being "closer" to Win32, I actually find it easier to move code to Cocoa. The initial confusion is that much of what you do by hand under Windows (WinMain setup, query event loop and message dispatch to the dialog handler or your window's WndProc event handler) is done for you. If you dig deep enough you'll find much of this is handled automatically in the NSApplication class and Cocoa run loop. As far as processing events, each Cocoa view class (including text views) have explicit methods to handle events rather than having to decode wparam and lparam values sent to your event handler function. For example, Cocoa implements a drawRect: method which is equivalent to WM_PAINT, mouseDown: which is equivalent to WM_LBUTTONDOWN etc.

I can understand wanting to maintain only one code base, but there will always be differences at the interface level. Check out Model-View-Controller if you haven't already. This is a very good way of organizing your code to minimise code changes from one platform to the next,

Also, setting up and maintaining interfaces using Interface Builder is far easier than using Visual Studio with Win32 (which seems geared towards MFC and .NET).