Here are few tips regarding the 4D v11 Plug-in development (particularly using the XCode):
- By default the Architecture mode for the Project Development Configuration is “Native Architecture of Build Machine”. This means if you are developing this plug-in on the Mac Intel machine, your plug-in will not work on the 4D if it’s running in the Rosseta mode. If you change to Deployment Configuration, you will notice that the architecture mode default is “ppc i386? (required for Universal plug-in). Of course, for the development it’s ideal to keep those settings (as it builds fast), but just want to share so that you don’t spend some time on this issue like me if this is your first v11 plug-in.
- If you want to change the bundle name (of course, you can do this manually after every build, but it’s a hassle), then you can do this from the Target Properties window. Simply right-click on the Target, and click the “Get Info” menu item. In the Properties window, to set the default bundle name, set the required name in the “Product Name” field (under the Packaging group).
- If you are migrating a plug-in, then most of the header file related to the GUI are now part of the Carbon Framework, and this Framework is already included in the default Project created by 4D Wizard. You can simply comment the those header include commands in your header file, and it should work. If you see a function is still undefined, then most probably it’s moved to some other framework, you can search on the web for this, or you can simply use the OS-X Finder search (it works very well). You can add the new Framework by right-clicking on the Project name and selecting Add -> Existing Frameworks.
- If 4D crash during your plug-in testing, and you think it was due to your plug-in code, then you can confirm this by looking at crash report generated by Mac OS-X. For this, when you see the OS-X Application crash report window, click on the Report and see the active threads calls. See if any of the thread was running your plug-in code. This might help quickly locate the function/code which is causing the problem.
- If you get the error “The plug-in method cannot be executed” on the deployed server on Windows, then most probably the target machine doesn’t have the required C/C++ runtime libraries. One simple way to check and fix this is to statically link all the run time libraries with your plug-in DLL by setting the “Runtime Library” value to “Multi-Threaded /MT” in the “Code Generation” section of your Project properties.
- Last, but not least, I was looking for a interactive debugger option in the XCode (similar to the one we get by using the “Attach to Process” in Visual Studio). After spending some time, I figured that out too. The process is simple, but a bit different and that’s what took me some time. The key point is that before you can debug the plug-in, you need to launch the 4D from the XCode. To do this, add the 4D application as the Executable from the Project Menu (using option “New Custom Executable”. Once you have done this, “Build and Go” should be enabled, click it and it will auto launch the 4D Standalone application. From there you can open the testing structure and now XCode will stop at the breakpoint as soon as 4D execute the corresponding code.
That’s all for today. I will keep adding more, as I experience them
