PureBasic Forum

This is a listing of the Mac only programming constraints. Maybe this list would help new users or porting programs from windows to the Mac. These are not bugs. This is not a complete list and I don't have a Windows machine to compare with so I need your suggestions. Updated 3/22/13 *

J. Baker has posted a detailed guide for submitting your app to iTunes with a further discussion here.

Tools - work within IDE as 'Tools'
-plistTool for OS X tool that works thru the debugger! - wilbert/J. Baker Updated 3/22/13 *
-PureMonitor for OS X tool that monitors CPU & threads, logs, and more! - J. Baker/wilbert Updated 3/14/13 *

Platform specific:
-use .app after program name, when creating an executable, to signal compiler to create a stand-alone application
-plists look like this.
-plist are found by right-clicking (cntrl+click) on the app and selecting 'Show Package Contents' and looking in 'Contents' folder
-plists are always replaced with a default after creating an executable (you must copy your plist over it every time)
-plists can automatically be copied to new executable with this code - jamirokwai
-a plist tool that works within the debugger plistTool for OS X - J. Baker/wilbert *
-windows must be moved down the height of the MenuBar (22 px)
-only one menu per program (they seem to be accessible from any window and must have a menu window open at all times!)
-pre defined constants of #PB_Menu_About, #PB_Menu_Preferences,#PB_Menu_Quit
-file path uses '/' instead of '\' (as in windows) eg. "user/WilliamL/Library/MyPrefs.txt" Multi-platform workaround
-colors designated by '$0000FF' are shown as BGR, pb commands like RGB(0,0,255) are shown as RGB
-color constants like #White are not defined on the Mac platform (but you can define them)
-color values in the API are word values ($FFFF) instead of byte values ($FF), see conversion here.
-pb preferences can be found here.
-supporting file are saved here updated info from J Baker
-Mac use a single button mouse and right clicks are entered by using ctrl+mouse to cause a right click. Laptops only have a singe button also. This does not work on the Canvas gadget but a work-around is here. Multiple button mice work fine on the Mac along with the scroll wheel and many use them (as I do).
-Freak explains how to compile 'universal binaries'
-Drawing can be done with CGContext functions for arcs, curves, blend modes that are antialiased.

Platform limitations:
-color in gadgets is generally not supported in pb - but may be added by API. Here is a chart of all gadget possibilities, and pictures of gadgets. Note: with 5.1 the color options are better.
-CalendarGadget on the Mac is just text (not like in manual) a CanvasCalendarGadget or datepicker are possible replacements.
-arrow keys don't work with AddKeyboardShortcut (yet!) but do work with Keyboard commands. (Arrow keys work in 5.10+)
-button height over (22 px ?) gives a square button instead of the rounded box (use 25 px for default button)
-printing is achieved by creating an image and printing it out (poor text rendering), text can be printed clearly by using the Carbon print manager (example) * (see next item)
-with version 5.00 printing size changed to 1/4 size. So to print 12 pt. text you have to use a 48 pt. font - same with images (x4).
-Console does not work on the Mac! Fred says OpenConsole() does nothing on OSX/Linux as there is no special console format.
-Tools are created using the 'Console' option when creating the executable
-Arr.Point(1) (eg.) will not work since Point is not a default structure. The structure can be defined.
-Color constants are not defined (eg. #White, #Black, etc)
-Text is limited to font and size - italics/underline/bold can be achieved by API in gadgets
-Text in images can achieve underline/strike-out with drawing commands

Platform suggestions:
-Arial (spelled with a capital A) and Geneva are safe fonts if you are coming from Windows (along with Monaco, Courier and many others). Also check to see if font is loaded.
-line feeds, as explained by Shardik, are:

Line feeds on the Mac are #CR$, on Linux #LF$ and on Windows #CRLF$.
MessageRequester() a #CR$ works on all 3 platforms the same

-use of FontID() is required [ eg. DrawingFont (FontID(F2)) ] - in another thread, freak says this is the correct behavior but it seems to be optional on Windows
- OpenWindow flags should be limited to #PB_Window_SystemMenu and #PB_Window_WindowCentered for compatibility or at least to the defined pb constants.
- see 'Re: Create threadsafe executable' by jesperbrannmark for his suggestions about using threads and programming on the Mac in general
- (your contributions)?

I strongly suggest looking at API List of the Mac for many additional abilities.

First I thought, this will be of little value to me,
as I do not currently have access to a Mac.

After reading all of this, I thought:
I would not want a Mac anyways.


No, this is wrong.

There is no OS I know of, that uses #LFCR$ as a line feed/line break!

Windows usually uses #CRLF$ for line break!
(The same also used by http.)

William,

I think your posting of collecting Mac only programming constraints is a very useful
idea. Especially newbies in Mac programming will see at once what pitfalls they
possibly might have to circumvent. But also more experienced programmers doing
cross-platform work would have a sort of checklist of what they have to pay attention
to.


That's right. Line feeds on the Mac are #CR$, on Linux #LF$ and on Windows #CRLF$.
But for example in a MessageRequester() a #CR$ works on all 3 platforms the same as
in this example (because presumably PureBasic takes care for that):


Until last year's summer I thought the same. But then I got a programming request to
develop an application for all 3 platforms. Since September 2010 I own my first Mac
and I began to program my first cross-platform application. And I have to confess that
it is a lot of fun to delve into the Mac's Carbon API to circumvent some of PureBasic's
current shortcomings...

A very good idea, I think!

It should be also useful to me, even if I will be more a "consumer" of tipps at the moment, and I'm probably not skilled enough to add many things to the list myself.


PS: made the post "sticky" to stay on top of the MacOS programming threads (beside the API list)

I can confirm freak's findings but nevertheless I would suggest to change the help for Mac. Especially for a beginner it is annoying and frustrating to read in the help for SetGadgetColor:

And this function is not contained in "Platform-dependant functions" with a hint that most Gadgets don't work with SetGadgetColor...

I have therefore compiled a html table (in the style of "Platform-dependant functions") which indicates for each gadget whether it works or doesn't work with SetGadgetColor and SetGadgetFont or whether an API workaround exists. Unfortunately I don't know a way to display this table as html on this board. Therefore I had to include it as an image...

Hint to Andre: it would be nice if you could integrate this table into the help files. Please send me a PM if you are interested...



Update 1: I have added SetGadgetItemColor to my table.
Update 2: I have changed the status of SetGadgetFont for the HyperLinkGadget to Red

@Shardik: thanks for your effort and the offer with the table )

But before I change the help, there is needed an official statement by the developers Fred / Timo. E.g. if they want such extensions in the help, if they will add (by workarounds...) mure functionality about the colors, etc.

I don't think there will be many changes in this area anymore (at least not until the day we switch to Cocoa as the underlying framework). So feel free to update the help accordingly.

> Hint to Andre: it would be nice if you could integrate this table into the help files. Please send me a PM if you are interested...

Don't add that table. Add a note in the topic for each function instead.

Timo,

I fully understand that there won't be many changes implemented in the
current Mac version of PB with its Carbon framework base. But do you
already have any plans in which PB version the porting from Carbon to
Cocoa will happen? I know that this task will take a lot of work because
all Gadgets will have to be reprogrammed and adapted to utilize the object
oriented Cocoa framework. In principle I would guess that this is almost as
much work as to develop a new Mac version of PureBasic from scratch...

Do you already know whether Carbon support will be ended completely or
will there exist a possibility to chose Carbon as an alternate subsystem?


That would be indeed the most user friendly solution...

Informations about (restricted) coloring possibilities on MacOS were added to the manual, for PB4.61...

This thread is pinned and seems to be important.

All these facts are correct also in the current version 5.10? Both listings (limitations and gadget colors) are from the year 2011 (PB version 4.6)...
Thanks!

No, it's no more accurate as we switched to Cocoa inbetween.

The limitations in the coloring of gadgets only apply if selecting subsystem Carbon. So SetGadgetColor() should work fine for all gadgets listed in the help for that command when using the Cocoa framework (default since PB 5.00).

Just stating out.

i have written a small program to display a splash screen using a .png image in an image gadget.

Works fine on windows 7. Moved whole thing to MAC and program runs but no image is displayed in the image gadget. If I add image at design time as i add the image gadget it works. Code as follows

;Imports/Using statements
UsePNGImageDecoder()
UseSQLiteDatabase()

;Add binaries to exe section
DataSection
splash: :IncludeBinary "Images\WorldC.png"
EndDataSection

;Display Splash Screen
window_Splash = OpenWindow(#PB_Any,0,0,500,200,"",#PB_Window_BorderLess|#PB_Window_ScreenCentered)
image_Splash = CatchImage(#PB_Any, ?splash)
gadget_Image = ImageGadget(#PB_Any,0,0,500,200,ImageID(image_Splash))

Delay(3000)

;Close Splash Screen
CloseWindow(window_Splash)

Looked at forum, not extensively but any help appreciated

Quick update on the above.

When i create the executable .app the splash screen shows Ok! Just not when running in compile and run.

It seems that the Delay() function is the culprit. Remove it and the image displays.

Instead, try implementing a timer for the splash screen.