>> Again, why does cross-platform code need to have references to
platform-specific view/controller types?
There are links between each Cocoa control class and its matching C++
control (which also owns a native MFC control).
Also links between the view and our C++ controller, to load window
Hi all
In a couple of months I'll be starting a macOS Swift 5 project and if
possible I'd like to separate as the business networking logic so that it
can be reused in a Windows app in the future.
Ideally I'd want to statically link the library but I've also considered
using dynamic libraries,
> On Aug 26, 2019, at 1:15 PM, Turtle Creek Software
> wrote:
>
> Our C++ is cross-platform. More importantly, we have a LOT of accounting and
> business logic in C++.
> To rewrite and test it would be 5 or 10 programmer-years.
I can understand the model and some of the controller logic
Our C++ is cross-platform. More importantly, we have a LOT of accounting
and business logic in C++.
To rewrite and test it would be 5 or 10 programmer-years.
We never found any way to have Obj-C members in C++ header files, except as
void *.
Also, no way to reference Obj-C headers from C++.
> On Aug 25, 2019, at 5:49 PM, Turtle Creek Software via Cocoa-dev
> wrote:
>
> No use of NSBridgingRetain or Release at all. Is that necessary under ARC?
Those functions are only for casting CoreFoundation types to/from Obj-C.
> The void pointers are mostly to text fields and controls,
>> @property (weak) GSOutlineWindowController *mainWindowController;
>>self.mainWindowController = [[GSOutlineWindowController alloc]
initWithWindowNibName : @"GSOutlineWindowController"];
[self.mainWindowController showWindow : self];
Sadly, nothing changes after the syntax changes.
A better way to investigate such issue is using the memory debugging tools in
Instrument IMHO.
That would let you see all stack traces of retain/release calls.
> Le 26 août 2019 à 04:14, Turtle Creek Software via Cocoa-dev
> a écrit :
>
> In GSAppDelegate.h
> GSOutlineWindowController
