Forum > macOS / Mac OS X
Illegal type conversion of "Pobjc_object"
dbannon:
--- Quote from: CCRDude on February 21, 2024, 02:47:52 pm ---....
I guess it leads to this question: which widgetset does the IDE pick to compile for when compiling a package?
Once the package has been added to the current project, it will be built with the projects current setting when recompiling the project, and later probably the same when directly compiling the package, but what is when the package is really new, hasn't been added to project or IDE yet?
--- End quote ---
As I understand it, a package should be widget set agnostic. But, obviously, many are not because the author has included platform or even widget specific code. For example, if you did use NSToolbar (and I understand you do not), then the package would be Mac only or you would need to add equivalent code for other platforms. So, depending on what a package does, its somewhere between trivial to make it cross platform and impossible !
Only you know whats in your package. But if it MUST be cross platform, I suggest testing early in the development process. Especially so when I hear you muttering words like NSToolbar. Generally, if you stick to LCL components and don't hit platform specific API, the result should be down towards the trivial end of the spectrum.
Davo
CCRDude:
I think we're still speaking past each other, but your answer lead me into a possible "solution" or "workaround".
I'll wrap my code into {$IFDEF LCLCocoa} to avoid that it causes this issue. I might also add a warning into a {$IFDEF LCLCarbon} that the mac user needs to use Cocoa instead of Carbon.
...
My main issue was user friendliness, and it seems even on a Cocoa IDE, Carbon might be preselected if the user does not manually pick a widgetset.
And an option to compile packages against different targets instead of the one currently active in the active project would be something helpful as well, but not a necessarity :)
dbannon:
--- Quote from: CCRDude on February 22, 2024, 12:15:09 am ---My main issue was user friendliness, and it seems even on a Cocoa IDE, Carbon might be preselected if the user does not manually pick a widgetset.
--- End quote ---
I was under the impression that was fixed in Lazarus 3.0, but don't know, I very rarely initiate a new project on the mac.
--- Quote ---And an option to compile packages against different targets instead of the one currently active in the active project would be something helpful as well, but not a necessarity :)
--- End quote ---
Thats why Lazarus has 'modes'. Button to the left of the green triangle "run", selects the mode. You setup a mode for every type of build you want. You can setup target, binary name, widget set, debug and release modes and even specific defines if you wish. If you have setup your FPC to be able to cross compile, you can build cross compiled binaries that way, else its a case of taking the sourse set to another machine.
Davo
CCRDude:
Default for projects is Cocoa, I just checked. Bad assumption on my part then.
--- Quote from: dbannon on February 22, 2024, 01:35:44 am ---Thats why Lazarus has 'modes'.
--- End quote ---
I use modes quite a lot, sometimes cross-compiling from Win32 to Win64, Linux and rarely macOS, having debug and release modes.
But how does that selection affect package compilation? The code as part of a project compiled, the code as part of a package open at the same time failed with this error.
dbannon:
--- Quote from: CCRDude on February 22, 2024, 09:09:35 pm ---
I use modes quite a lot, sometimes cross-compiling from Win32 to Win64, Linux and rarely macOS, having debug and release modes.
But how does that selection affect package compilation? The code as part of a project compiled, the code as part of a package open at the same time failed with this error.
--- End quote ---
Not sure how others work, but I would get the code working as an application first, tested as much as possible on all the needed platforms and only think about packaging once the core code is proven.
Then, when testing a package, you would normally use that package in an application, and that application, again, can have 'modes'.
My real point was the importance of cross platform testing, one way or another, early in the process and sticking with LCL components.
Davo
Navigation
[0] Message Index
[*] Previous page