Getting started in Fire/Oxygene

  • Mac Mini M1
  • macOS 13.4
  • RemObjects Fire 11.0.0.2847 (develop), built on cherry, 20230630-155431
  • Xcode Version 14.3.1 (14E300c)

6 years after my last venture into the world of RemObjects and roughly 20 years since the first - I was around at the start of Chrome! - I have returned with a renewed appetite for coding.
I’m following the “Your First Mac App with Fire” page at Your First Mac App with Fire, but I am running into a couple of issues. I’ve just added the code for the UI elements…

    [IBOutlet] property edit: NSTextField;
    [IBOutlet] property label: NSTextField;

to the public section of the MainWindowController class definition. But when I switch back to Xcode, I do not see the newly added components. What am I missing in order to get the code in Fire to sync with the UI in Xcode?

UPDATE: The .sln builds and the project runs, but all I see is a blank window. No controls at all…

1 Like

Welcome back! :hugs:

To re-sync with Xcode, you either have to re-select “Edit User Interface Files in Xcode” on the file (or project), or you need to check the “Update Xcode UI Project on build and save” option in project settings, in which case this should happen automatically when you build:

I tried re-enabling the option in the preferences. I even deleted everything and started again. Now when I build, I get this. It’s as if it doesn’t even recognise it as an Oxygene project…

That seems to be unrelated, it looks like there are just syntax errors in your .pas file.

Can I see the project as it is now?

This is the MainWindowController.pas…

namespace MacApp1;

interface

uses
  AppKit,
  Foundation;

type
  [IBObject]

  public class(NSWindowController)
  private
    method SayHello(sender: id);
  protected
  public
    [IBOutlet] property edit: NSTextField;
    [IBOutlet] property label: NSTextField;
    constructor;
    method windowDidLoad; override;
  end;

implementation

constructor MainWindowController;
begin
  inherited constructor withWindowNibName('MainWindowController');

  // Custom initialization
end;

method MainWindowController.windowDidLoad;
begin
  inherited windowDidLoad();

  // Implement this method to handle any initialization after your window controller's
  // window has been loaded from its nib file.
end;

method MainWindowController.SayHello(sender: id);
begin
  label.stringValue := "hello, " + edit.stringValue;
end;

end.

No worries!
the line MainWindowController = public class(NSWindowController) got deleted!!

Still nothing in Xcode…

SCR-20230704-ptdm

that’d do it!

Not even when you re-select “Edit User Interfaces in Xcode”? does the .h file in Xcode get updated and show the new members?

Where exactly do I find that option?

I’ve got this…
SCR-20230704-qdfi

or this…
SCR-20230704-qdks

I don’t see anything with the wording “Edit User Interfaces in Xcode”…

Sorry, yes, that’s the same. When you right-click on the Project is has the caption I quoted; it seems on individual files it just says “Edit in Xcode”. my apologies for the confusion. :wink:

When I go to Xcode, as well as a blank UI with neither of the controls added in the code, I also see see a warning and an error. The warning has the following text…

Traditional headermap style is no longer supported; please migrate to using separate headermaps and set 'ALWAYS_SEARCH_USER_PATHS' to NO.

while the error says…

Cannot code sign because the target does not have an Info.plist file and one is not being generated automatically. Apply an Info.plist file to the target using the INFOPLIST_FILE build setting or generate one automatically by setting the GENERATE_INFOPLIST_FILE build setting to YES (recommended).

In Xcode, if you open and expand the project tree, it should looks something like this:

the Classes.h file should be getting updated with your new members when you select “Edit in Xcode”. Check that, if you don’t see changes you expect.

You will want to select the MainWindowController, to edit it: e.g.

I think those are safe to ignore. Do note that you don’t want to press build in Xcode.That will fail and/or not produce anything.

it does get updated correctly for me:

If I select the h classes option under Generated Code

I see this…

//
// This code has been automatically generated by RemObjects Elements for interaction with Xcode. 
//
// It is not meant to compile, and any changes will be ignored and discarded. 
//

@interface AppDelegate: NSObject



@end

@interface MainWindowController: NSWindowController

@property (weak, nonatomic) IBOutlet NSTextField *edit;
@property (weak, nonatomic) IBOutlet NSTextField *label;


@end

It seems to show, at least that information about the 2 added controls is making it through to Xcode, if not to the main screen…

that’s good that’s what expected to happen.

The outlets will appear on the right hand side of the XIb editor: and you can drag them to connect them to controls if you place any:

Okay! I think we’re getting somewhere. The mistake I was making before was to think that the action of specifying the two controls in code would be enough for them to automatically appear in Xcode. I didn’t realise that they had to be created in the UI designer, then linked to their code counterparts!

I’ve now got a screen which looks like your last screen (now that I found the “Show the connections inspector” button).

What I don’t have is a palette of components from which to populate the windows as described here…

Aha! ⇧⌘L aka Show Library. Now we are in business :wink:

Ah yes. the way this works, these “outlets” are just variables you can connect to items in your xib. The xon defines the actual items (and their location and properties) so you have to add them there, and then draw the connection.

This may have changed in recent Xcodes. you can press Command-Shift-L to show the Library of components.

I’ll update the article.

Thanks for your help and patience, marc!

The other thing I was wondering… I see that you have addressed Java with Elements, but have you ever considered one of the Java Byte-code languages, specifically Scala? I’ve been exposed to Scala as a by product of building some Java extension for the Bitwig Studio DAW, and I reckon that for someone interested in languages such as yourself, Scala would definitely be of interest.

Here’s an extract from one of my recent projects…

1 Like

I haven’t looked at Scala before, no. I’ll check it out!