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 :)."
Related
I am trying install OpenGL on VS2010.
I use this tutorial.
And I get the following error:
Unable to start program 'C:\Users\s151310\Tutorial 0.3.8\frameworkD.lib'.
The specified file is an unrecognized or unsupported binary format
How can I fix this?
Actually don't have to install anything at all to start OpenGL development with Visual Studio. As long as you limit yourself to OpenGL-1.1 and core Win32 APIs everything is already in place for you.
However to get modern OpenGL features one must use the so called extension mechanism to load pointers to functions of newer versions – a tedious and uninteresting process. Hence extension loader wrappers have been developed.
Also creating a window and setting up a matching OpenGL context is laborous as well. So you want to use some framework for that two.
Extension loader wrappers and frameworks are 3rd party libraries that need to be installed separately.
Unable to start program 'C:\Users\s151310\Tutorial 0.3.8\frameworkD.lib
Why are you trying to execute a library file? This is the framework library that's supposed to be linked into your executables. So this raises the question: How did you setup your project, specifically which build options did you configure. Without that I can't give better advice.
I'm just trying to get my foot inside the OSX world after recently getting a MAC.
Over the past months i haven't successfully built a working VST 2.4 yet. I simply dont get why: the projects in the vst examples work (somewhat) out of the box, but my own projects fail to work.
I've mirrored every build setting exactly (including info.plist and pkginfo), double checked that the contents of the vst.app is identical, correctly gets build as vst with correct extensions etc., and the code is virtually the same, however my vst doesn't get recognized in any of the hosts i tried.
The commandline even is identical for the build.
I've tested my VST with the included minihost vst tester, and it passes and works - but still wont be recognized. I even checked the exported symbols with nm and they look correct (ie. createEffectInstance is correctly exported).
What gives? There must be some hidden build setting somewhere that i haven't discovered that seems to disqualify my VST.
Probably the most obvious but overlooked setting: are you building as 32 or 64 bit? You need to make sure that the bitness matches your host, otherwise the plugin won't be loaded (which, btw, might explain why the plugin could load in your self-built minihost and not another sequencer). To ensure compatibility with most hosts, I'd go for 32-bit build.
Also, here's a tutorial I wrote on the subject awhile back. However, you claim that you are doing everything correct with the Info.plist and whatnot, but perhaps you missed a small step:
http://teragonaudio.com/article/Making-a-VST-plugin-from-scratch-with-Xcode.html
Another potentially useful tool is MrsWatson (disclaimer: I'm the author of that program). It's a command-line VST host which can be used to provide diagnostic information about VST's, and also is designed for plugin testing and debugging. Because of the 32/64 bit difficulties with plugins, on Mac OSX the program ships separate 32 & 64 bit binaries rather than using a universal binary.
You should try running the following command on your plugin:
mrswatson --verbose --plugin /path/to/wherever/you/put/the/plugin.vst --display-info
If you see a list of parameters and other info, then it should be kosher and able to be loaded in most sequencers. Hope this gets you on the right track!
Try using your debugger to watch what Dispatcher() calls your host makes. Check if there are any differences between your plugin and the included example projects. In my experience a host will usually abort loading a plugin immediately after a Dispatcher() call raises an exception or returns a result the host doesn't like for whatever reason.
Ok, I went through great lengths but I finally got my integration to quickbooks working on my VB6 application. It works perfectly on my build machine. I actually installed the qbdsk11 on my build machine and worte and tested the code. The ONLY new reference in the project is the QBFC11.dll.
So, I added the QBFC11.dll to my innosetup, told it to do a regsvr on the dll, and hoped this was enough.
NOT.
First, during install, I get a failure to register the dll. Apparently, this DLL isnt meant to be registered?
But the .DLL was put in Windows System32, so I tried my program anyways...
NOPE. Doesnt work. I get a runtime 91, about an object variable not set. Which makes sense, if it cant create the object.
So, for grins, I moved a copy of the .DLL into the program folder, next to my executable.
Same thing. Runtime error 91.
So, i then grab the whole qbsdk11 installer and install it on this machine. I figure I can make it an additional download for people who want to use this extra functionality.
But no, even with the whole SDK installed, I still get the same runtime error.
I have not been able to find any CLEAR information on how to proceed. I'd prefer for this to be part of my base install. But apparently something still just isn't right.
What did I miss? How do I fix this? I don't even know what to try next.
If you're using QBFC11, you must install the QBFC11 redistributable components with your application. You can find instructions on how to do this in the QBSDK Programmer's Guide in the section titled Redistributing SDK Components With Your Application, subsection Using Installers and Merge Modules.
The most likely cause of the runtime error you're currently getting is the manipulation of the QBFC11.DLL that you did before you installed the SDK. I would start again with a clean OS image so that you can get the proper procedure down.
I have a custom framework that, following the advice in Apple's Framework Programming Guide >> Installing your framework I install in /Library/Frameworks. I do this by adding a Run Script build phase with the following script:
cp -R build/Debug/MyFramework.framework /Library/Frameworks
In my projects I then link against /Library/Frameworks/MyFramework and import it in my classes like so:
#import <MyFramework/MyFramework.h>
This works very well, except that I always see the following message in my debugger console:
Loading program into debugger…
sharedlibrary apply-load-rules all
warning: Unable to read symbols for "/Users/elisevanlooij/Library/Frameworks/MyFramework.framework/Versions/A/MyFramework" (file not found).
warning: Unable to read symbols from "MyFramework" (not yet mapped into memory).
Program loaded.
Apparently, the compiler first looks in /Users/elisevanlooij/Library/Frameworks, can't find MyFramework, then looks in /Library/Frameworks, does find MyFramework and continues on its merry way. So far this has been more of an annoyance than a real problem, but when runnning unit tests, gdb stops on the (file not found) and refuses to continue. I have solved the problem by adding an extra line to the Run Script Phase
cp -R build/Debug/MyFramework.framework ~/Library/Frameworks
but it feels like sello-taping something that shouldn't be broken in the first place. How can I fix this?
In the past months, I've learned a lot more about frameworks, so I'm rewriting this answer. Please note that I'm talking about installing a framework as part of the development workflow.
The preferred location for installing a public framework (i.e. a framework that will be used by more than one of your apps or bundles) is /Library/Frameworks[link text] because "frameworks in this location are discovered automatically by the compiler at compile time and the dynamic linker at runtime."[Framework Programming Guide]. The most elegant way to do this is in the Deployment section of the Build settings.
As you work on your framework, there are times when you do want to update the framework when you do a build, and times when you don't. For that reason, I change the Deployment settings only in the Release Configuration. So:
Double-click on the framework target to bring up the Target info window and switch to the Build tab.
Select Release in the Configuration selectbox.
Scroll down to the Deployment section and enter the following values:
Deployment Location = YES (click the checkbox)
Installation Build Products Location = /
Installation Directory = /Library/Frameworks
The Installation Build Products Location serves as the root of the installation. Its default value is some /tmp directory: if you don't change it to the system root, you'll never see your installed framework since it's hiding in the /tmp.
Now you can work on your framework as you like in the Debug configuration without upsetting your other projects and when you are ready to publish all you need to do is switch to Release and do a Build.
Xcode 4 Warning
Since switching to Xcode 4, I've experienced a number of problems with my custom framework. Mostly, they are linking warnings in GDB that do not really interfere with the usefulness of the framework, except when running the built-in unit-test. I have submitted a technical support ticket to Apple a week ago, and they are still looking into it. When I get a working solution I will update this answer since the question has proven quite popular (1 kViews and counting).
There's not much reason to put a framework into Library/Frameworks, and it's a lot of work: You'd need to either do it for the user in an Installer package, which is a tremendous hassle to create and maintain, or have installation code in your app (which could only install to ~/L/F, unless you expend the time and effort necessary to make your app capable of installing to /L/F with root powers).
Much more common is what Apple calls a “private framework”. You'll bundle this into your application bundle.
Even frameworks intended for general use by any applications (e.g., Sparkle, Growl) are, in practice, built to be used as private frameworks, simply because the “right” way of installing a single copy of the framework to Library/Frameworks is such a hassle.
The conventional way to do this is to have your framework project and its clients share a common build directory. Xcode will search for framework headers and link against framework binaries in the build folder first, before any other location. So an app project that compiles and links against the header will pick up the most-recently-built one, rather than whatever's installed.
You can then remove the cp -r and instead use the Install Location build setting to place your build product in the final location, using xcodebuild install DSTROOT=/ at the command line. But you'll only need to do this when you're finished, not every time you rebuild the framework.
Naturally, when you distribute your framework it should be installed in /Library/Frameworks; however it seems odd to me that you're doing that with the test/debug versions of your framework.
My first instinct would be to install test versions under ~/Library, as it just makes setting up your test and debug environment that much simpler. If possible, I would expect the debug/test framework to be located in the build tree of the version I'm testing, in which case it's installed as a Private Framework for testing purposes. That would make your life much simpler when it comes time to deal with multiple versions of your framework.
Ultimately, it doesn't matter where the framework is located as long as your application or test suite loads the correct version. Choose the location that makes testing/debugging/development easiest.
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.