I can certainly see the benefit in extending the declare functionality to make it easier for us Xojo secs to extend our apps, as well as to make it easier for other developers to migrate to Xojo.
I think the big issue is that declares are platform specific, where as Xojo is X-plat and as we know declares can add cause headaches not only for us who understand what we’re doing, for those who don’t and of course Xojo support.
Adding a NSControl to an application breaks the Xojo view hierarchy.
Declares are also what sets Xojo apart from other X-plat tools as it allows us to build better apps and workaround for issues that we discover.
I know this is not related to this thread, but can you give an example? Over the years I have developed some controls which do that and never ran into any troubles. For example to get scrollbars on a canvas I put an NSScrollView between the parent of the canvas and the canvas in the open event of canvas has worked for years without problems.
[quote=233237:@jim mckay]
I don’t see where it would become a problem, since there would really be no need for it outside of declares, but a huge plus for declare readability (IMHO)[/quote]
You’ve never had the joy where one header defines bool to be int and another byte and just reordering things changes how code behaves in an enormous way
And because it was “done right” they dont conflict because they both check to see if bool is defined before they do their thing
That kind of havoc could easily arise when you have many libraries defined by yourself, others etc
All your code looks right but doesn’t work
It may or may not work, but Joe has said on many occasions that doing what we do to add NSControls to a Xojo application breaks the Xojo view hierarchy, which can lead to crashes. It may not at the moment, but it may in the future.
There’s a feedback case to not only make it easier to ‘insert’ NSControls but also without break the view hierarchy. <https://xojo.com/issue/30708>
Hopefully once we have an official sanctioned method, you won’t have to worry about it. We’re diverging, perhaps this should be moved to a different thread?
The way I understand it, you shouldn’t change the hierarchy. Best to add to it. I believe it’s OK to use a canvas as a parent to add a dynamic NSControl as a subview at runtime, but it’s bad to take Xojo created controls and move them to a different superview. It’s also bad to modify the existing classes (runtime subclassing or using objc_addmethod to alter an existing Xojo class). And by OK, I mean it shouldn’t be a problem, but is not officially supported. In iOS we have iOSUserControl specifically for this, but not for OSX yet. Adding an NSControl to a canvas also allows Xojo to manage the layout properly.
[quote=233317:@Norman Palardy]That kind of havoc could easily arise when you have many libraries defined by yourself, others etc
All your code looks right but doesn’t work[/quote]
I can understand that there is a potential for havoc, but I’ve had, for example, NSRect defined in multiple modules in the same project and never had any major issues (that didn’t take 2 seconds to fix). I still think it would be less havoc-prone to be able to define the types to be used throughout a project and find and fix any issues, than to translate types to Xojo types, declare by declare and have to track down the offender later…
“oh wait that one int32 where the api calls for CFIndex was wrong and I just spent 2 days on nothing” is fun too.
Thomas’ problem is not entirely solved with the Desktop 32 vs Desktop 64 checkboxes for defining stuctures and properties. This issue is because of the difference in behavior between Windows “native” (Visual Studio) and OS X compilers, versus the behavior of Xojo.
The problem is that a structure has to be passed to the ZLIB library including uInts and uLongs. MS VS C++ defines uInt and uLong as 32 bits for BOTH 32 and 64 bit Windows builds. XCode defines uLong as 64 bit.
A Global Property defined as this structure is used in dozens of places throughout the code. In some half dozen other places, declares of functions in the external ZLIB DLL pass a variable declared as this structure.
As far as I can tell, because we don’t have a way to define a structure differently for Win64 versus 64-bit OS X and Linux, we need two structure definitions with different names, two global properties with different names, and a ton of nearly duplicate code for external library declares and internal code referencing this structure, all surrounded by:
#If TargetWin32 #If Target64Bit
// Building for 64-bit Windows #Else
// Building for 32-bit Windows #Endif #Else
// Building for everything else #EndIf
sprinkled through out the code.
Or am I missing an obvious way of making this cleaner?
