I'm curious if anybody could help with a problem I'm having. I just downloaded and installed the SDL 2 framework, along with the example programs that come with it, from Mercurial (http://www.libsdl.org/hg.php) onto OSX Mavericks (10.9).
I am attempting to run the example native cocoa code in Xcode 5.1.1, which includes the files testnative.h, testnative.c, and testnativecocoa.m that come from the tests folder in the Mercurial download.
I am successfully able to build the program, but as soon as it hits the function SDL_CreateWindowFrom(native_window), the program crashes and highlights the following line of a file called SDL_cocoakeyboard.m:
nswindow = ((SDL_WindowData*)window->driverdata)->nswindow; Thread 1:EXC_BAD_ACCESS (code=1, address=0x8)
The only thing I did with the original files was change the include headers from SDL.h and SDL_syswm.h to SDL2/SDL.h and SDL2/SDL_syswm.h in testnative.h. I've included both the cocoa and SDL2 frameworks in the program, and I turned off automatic reference counting, which was necessary to get the example code running.
I have no idea where else I could be going wrong, since the code before the aforementioned line looks and runs fine (it's able to create the cocoa window before it crashes).
Any insight on this issue would be great. Thanks in advance!
I was wrong in the comment, driverdata is null (never initialized), some code like SDL_cocoawindow.m:SetupWindowData would be required, but SetupWindowData is static (not global) and adding a minimal initialization would require SDL_cocoawindow.h(but isn't public).
So, my guess (maybe I'm wrong) this testnative isn't working, at least not with current SDL2 (the wrong #include should have been a sign) but a fast look into SDL2 shown there's enough cocoa code to hope there are other ways to get a native window working.
A good start How to set up a SDL 2 project for OS X in Xcode 4
Related
I'm adapting an air extension for PC to the Mac. Successfully creating a project
which "ought to" work, but instead I get
Error #3500: The extension context does not have a method named
The packaged ANE is being loaded successfully, but no calls work. I suspect
that the initializer is not being called (and nothing is complaining about it).
My evidence being that I removed the initializer and finalizer from the C project
and the behavior did not change.
Any suggestions?
Versions: Xcode 3, Air-15, Flex 4.13, Flash Builder 4.7
Edit: more information; I discovered that exporting the application as a release build/signed native installer, then installing and running the application, it works
(well, still needs debugging, but the extension methods are being reached). So the
question simplifies to "what is wrong with the flash builder environment"
It is apparently impossible to use flash builder in conjunction with air native extensions on OSX.
Creating the extension context works without complaint, but calling any of the functions provided
results in "error #3500: The extension context does not have a method named ..."
It cost me a lot of time (and therefore my company's money) to discover that the ANE is actually fine, and can be
invoked outside of flash builder, by an appropriate command line, or by packaging a release executable.
This total package of behavior is very unsatisfactory, and has been known about for at least two years.
Even with the workaround (release packaging, or invoking using a command line) the workflow is
severely degraded.
--
for reference, the most helpful explanation of the workaround is at this URL
http://riawanderer.com/2012/03/27/working-with-air-native-extensions-on-the-mac/ note the date of this post!
then search for the panel that follows the text
"Now that simple demo code is ready, let’s run and see what does it do. When you run the app you should see below error indicating that Flex Builder Bug exists :)."
My question is the exact opposite of this earlier one. I am working on an open source application, which is published under 2 forms, pre-compiled binaries and source code.
I installed the pre-compiled binaries and it works perfectly, with a nice little icon in the dock.
I compiled the source code successfully, but I get a runtime error when I launch it. After investigation I suspect this app needs command-line options to run correctly.
So my question is: if my assumptions are correct and the working version is actually defining command line arguments, how can I retrieve the CL arguments from the packaged app?
If it makes any difference, the app I'm talking about is Cyberduck, and I'm running OS X Version 10.8.2
The issue is not the command line. From the code here
// Get an instance of the non-localized keys.
CFDictionaryRef bundleInfoDict = CFBundleGetInfoDictionary(mainBundleRef);
if(NULL == bundleInfoDict) {
fprintf(stderr, "[Launcher Error] No info dictionary.\n");
exit(-1);
}
where mainBundleRef refers to the .app bundle.
The problem is that the Info.plist inside the app (/Applications/Cyberduck.app/Contents/Info.plist) does not have the normal keys in it. It has been corrupted in some way.The one in the code repository looks OK at a glance. For information about the structure I would look at the Apple development document.
The easiest fix would be to redownload and install the application.
I have a Carbon-based project that compiles on XCode 3, but fails on XCode 4.
It can't seem to find any Carbon or QT functions, even though I've included
and #include
I get lots of errors like this:
No member named 'InitCursor' in the global namespace
I tried re-adding in the Carbon.framework from the System/Library/Frameworks folder
The InitCursor function, along with pretty much everything else in QuickDraw, was removed in Lion. You will need to remove your uses of all removed APIs, and probably replace most of them with more modern replacements.
This is a non-trivial task, but it is necessary if you want to build with modern tools and target current and future versions of Mac OS X.
It's been a long time coming, too; QuickDraw has been deprecated for years.
Much of Carbon is still supported, and you should find that you are not getting errors about those APIs.
You mention Qt; I've heard that there is a Cocoa version of Qt now.
Xcode 3.25, Mac OS X 10.6, 10.5 compatibility required.
I have a Mac Xcode project, which mixes Cocoa and C/C++. Some legacy modules require a C-only header.
I created a C header file: myCTypes.h
I wish to use a CGPoint in that header.
Compiling generates an error: CGPoint is not defined. OK, no problem, so I'll just:
#include: "<CoreGraphics/CoreGraphics.h>"
Unfortunately, I get this:
error: CoreGraphics/CoreGraphics.h: No such file or directory
Hmm. OK, so I'd best add the framework. But if I right-click on the frameworks group within Xcode, and try to "Add an existing framework", CoreGraphics does not show up in the list. Grr.
So I try to add it manually, navigating my way to System/Library/Frameworks. Nup, not in there either.
So I look in the 10.5 SDK paths, and once again, there's a lot of CoreXXX frameworks in there, but no CoreGraphics.framework.
Can someone please tell me what I'm doing wrong here? What do I need to use CGGraphics in that header? Cheers.
EDIT
This was solved by:
#include <Carbon/Carbon.h>
(But if anyone wants to tell me if this is good practice or not, please feel free. Cheers.)
Core Graphics is part of Application Services, so that's the header you should include:
#include <ApplicationServices/ApplicationServices.h>
You can include Carbon.h if you want, but its total length after preprocessing is very long, so you should include it only when you absolutely have to (e.g., for Carbon Events hotkey stuff) in order to keep your build times down.
Well i know this topic is super old but i wanted to answer pqnet`s question in the comments (can't comment on it because I have less than 50 rep points :( )
now to the point: Yes, today anyway, you can add only core graphics framework if you like.
Click on your project in the project navigation pane; build phases; link binary with libraries. Then, chose coreGraphics; then click add.
Thats all, enjoy.
I managed to include some of the functions required by my project with this:
#include <CoreGraphics/CGWindow.h>
But I guess other functions are in other headers under CoreGraphics
Additional info:
Catalina
Xcode 11
PS: if some of Apple guys read this, please, add headers in your documentation!! And examples!!
I have a project which has several components loaded by a single preloader swf.
The preloader swf is strictly AS3 (No flex) and uses Loaders to load two different swfs which both use the flex library (Statically compiled, not rsl).
When I compile all three under linux and run the resulting preloader, one of the swfs fails to load properly, and the exception below (at the bottom of this post) is thrown.
If I compile the same component using the same ant task in windows, the component loads just fine without error. The windows file is also 683 bytes smaller.
This is true using the flex SDK 3.2.0 and 3.3.0 under linux and windows.
Have you seen this type of behavior? Can you offer any suggestions for why it might be happening, or how to determine what is wrong?
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at mx.managers::FocusManager/activate()
at mx.managers::SystemManager/activateForm()
at mx.managers::SystemManager/activate()
at mx.core::Application/initManagers()
at mx.core::Application/initialize()
at OC_Footer/initialize()
at mx.managers::SystemManager/http://www.adobe.com/2006/flex/mx/internal::childAdded()
at mx.managers::SystemManager/initializeTopLevelWindow()
at mx.managers::SystemManager/http://www.adobe.com/2006/flex/mx/internal::docFrameHandler()
at mx.managers::SystemManager/docFrameListener()
So wait, are you using different version of the SDK in each platform? That would certainly account for some differences (at the very least in the size of the swf...)
IIUC you get this error when you're loading the page in the browser, right? It's hard to tell from just the stack trace what's wrong, but I can tell you that I used to get a similar error on Windows and it had to do with keyboard events (e.g. using the tab key to move between elements when popups are visible, and similar stuff). Sorry I can't offer a more accurate diagnosis.
I'm not sure I've solved the real problem (Why the compilation was different under different OS's), but I have found that the newer version of the flex SDK does not exhibit the same issues.
I created a bug for the issue here:
https://bugs.adobe.com/jira/browse/SDK-20147
The short of it is, build 3958 (The one default with flexbuilder at the time that I created the bug -- This may still be true) appears to have a number of minor bugs. Upgrading the flex SDK to build 4852 alleviates the symptoms, and I can build projects successfully in a number of environments.