GNUstep - Can GORM open Interface Builder-created NIB files or not? - grails-orm

I have created a working project in XCode + Interface Builder on my iMac. I would like to port it to my Windows XP machine, which has GNUStep installed (and it seems to work okay as long as I create programs from scratch on there). I have transferred all the files to my Windows machine, created a new project in ProjectCenter and compiled everything.
It works to that point.
My problem is with Gorm. I have used the Interface Builder to save a NIB file (instead of the default XIB file) and it basically creates a folder ("ProgramName.nib") with two files inside: "designable.nib" and "keyedobjects.nib". I have tried all kinds of different methods to actually open these files in Gorm to see the interface objects, but it just won't work (which is to say, nothing happens when I try to open a file - Gorm launches okay, but there's no evidence of the NIB file's menus or other objects). I was under the impression that Gorm could open NIB files (there's even a reference to the "keyedobjects.nib" file on the Gorm webpage). Is there something that I am missing?
Thanks,
Peter

Gorm should be able to open .nib files.
If it does not, you should either create a bug report on the GNUstep tracker or send an email to the developer list and ask there about your problem loading the .nib files.

Related

MainMenu.xib not found after base localization was disabled in Xcode 5

I'm working on a Mac OS application that should be supported on 10.7. The project was created under Xcode 5 running on Mavericks with base localization initially enabled.
I've now removed base localization so that I can support 10.7 but have been unable to get the application to run at all anymore, either on 10.7 or 10.9 because Xcode generates the following error:
Unable to load nib file: MainMenu.xib, exiting
So I added a new MainMenu.xib file via File - New File - MainMenu. I wired up the AppDelegate object and set the delegates.
Back in the project file, I made sure of the following:
MainMenu.xib is part of the build target's Copy Bundle Resources build phase.
Made sure that MainMenu.xib is selected in the targets General - Main Interface setting
Checked in the File Inspector for MainMenu.xib and saw that it was localized into English and that a checkmark was checked beside that.
I can't think of what else should be set. I've even created a new, empty project for testing. With that, I made no changes other than to delete the base localization and then attempt to re-add a new MainMenu.xib and follow the steps outlined above, but to no avail. That build fails as well when launching in Xcode with the same error.
I've even tried using a different XIB file with a different name (yet still one setup as a MainMenu) but all that did was change the error message to reflect the new XIB name I had specified in the settings.
While I'm sure base localization is great, I'm hoping to support 10.7 users so I don't believe that keeping base localization enabled is an option for me.
Any help (even if it's pointing out the obvious) would be much appreciated.
I think I finally found the culprit. When the base localization was deleted, a new MainMenu XIB file needed to be created and selected in the target. Under Targets - Deployment Info - Main Interface the drop-down menu lists all available XIB files in the project that you could specify as the Main Interface. Naturally, I selected my newly created MainMenu.xib file and that's where the problems started.
After diff'ing the changes that Xcode had made to the Project Settings file, I noticed that in the working copy, the Main Interface key was set to MainMenu whereas in the non-working copy the key was set to MainMenu.xib, which is precisely what was in the drop-down menu.
Manually removing the .xib extension from the Targets - Deployment Info - Main Interface combo-box appears to have things working again. Note that it was the combo box in the first place that added the .xib suffix.
There might be more at play here, but that simple change has resulted in the program now properly launching.

Unable to find nib named error when trying to load nib from within a framework

I've got a 'Main app' and a 'Helper app' (sandboxed, if that matters) that share a private framework including some resources, nib files, sound files etc.
The framework gets called and used by both apps without issues. However from within in the Framework code I have a NSViewController that loads a nib file which is included in its resource folder. This seems to work as long as its called by the 'Main app'. Doing the same with the Helper app (a login item) however does not work and fails with an "Unable to find nib named" error.
The actual 'Framework' is copied to the Main app's 'Frameworks' directory and I use a #rpath in the helper app to find the framework: #executable_path/../../../../Frameworks
This setup seems to work just fine however at runtime it seems the frameworks code tries to find the named Resource under the helper app's Resource folder and not under the Framework's resource folder. Is there a setting or some flag that I can set in xcode to make the framework's always look under the exact path where the framework's executable/library is installed?
It seems the only solution is to copy the framework to the 'Helper' app as well. Resources otherwise do not get loaded if the framework was just a symbolic link to the actual framework placed inside the main app.
What you can do is making your Framework dynamic or shared like described here Dynamic Library Programming Topics
Though it is a bit of a complex process, but a very nice feature.
What else can help you?
Perhaps editing the Library Search Paths or the Framework Search Paths under your Build Settings in Xcode. there you can specify additional search paths to look for.
Even though, I would not copy the Framework to the Main app's dir. I would leave it in one place on your disk, add them to your project (Main and helper) and add the specified search path.
By the way: How is your framework implemented? Is it a folder, is it compiled, or is it only code files?

Using a System Plug-in (.saver bundle) inside a Cocoa Application as a Resource

I'm new with Cocoa / Objective-C development and I have a question.
Last week I had to create a SWF based Screensaver for Mac, and as I didn't find a free-compatible solution for Mac OS X Snow Leopard / Lion, I created a .saver bundle with Xcode 4. It creates inside a webview and loads inside the SWF file.
You must place the SWF file inside the Resources folder inside the bundle to make it work with different SWFs.
And now, I'm trying to code a Cocoa Application to do it automatically.
It has a simple user interface so as the user can select a SWF file. Then the code makes a copy of my previously build .saver file (I have the path hardcoded), places inside it a copy of the SWF file, and saves it where the user indicates in a save panel.
And here comes my question. Now I have the path of the .saver file hardcoded, but I need to have it as a Resource inside my app. Would it be possible? How could I use/access it?
Thanks for your help and time!
Your application already has at least one resource, assuming you didn't delete the MainMenu nib. Add your .saver bundle to that build phase. In the app's code, get the URL to the screen-saver bundle the usual way.

Windows Script Host Object Model's Interop.IWshRuntimeLibrary.dll referencing same directory as executable

I have an application that creates desktop shortcuts. To do this I have to reference the Windows Script Host Object Model. When I add it as a reference, it always creates the DLL, Interop.IWshRuntimeLibrary.dll, in the obj\x86\Debug directory, then references itself to it, rather than looking at wshom.ocx. Even if I add reference wshom.ocx it reverts to saving the file in the obj\x86\Debug directory. The problem is if I move my application to another computer without that DLL being present, the program fails to run.
What's the proper way of handling this situation?
Thank you
Your best bet would be to ditch the Windows Scripting Host completely. Here's a link to a method for creating shortcuts without relying on the WSH. It still uses COM though.
http://vbaccelerator.com/home/NET/Code/Libraries/Shell_Projects/Creating_and_Modifying_Shortcuts/article.asp
Here is a class that someone created that you can use:
http://www.msjogren.net/dotnet/eng/samples/dotnet_shelllink.asp

Working Directory in Objective-C and Xcode: debug mode vs. executable

I am writing a program in Objective-C using Xcode. My program creates a file as follows:
[#"" writeToFile:fileName atomically:YES encoding:NSUTF8StringEncoding error:NULL];
I would like the file to be created in the same directory as the executable. When I run the program from Xcode, the file is created in the debug directory as expected.
However, when I run the .app file, the file is created in the root directory. How can I get the program to create a file in the directory where the .app file is located.
Thanks a lot.
EDIT: This is a MacOS application
EDIT2: Well, it seems that I shouldn't be writing to the .app directory. Thanks bbum and Paul R. What is the proper way to do it? To be more concrete, here's what I am doing: each time the user clicks a button in the application, a piece of hardware connected to a serial port will send a bunch data which will be written to a new file. This can happen any number of times while the application is running, so numerous files may be created. I would like them all created in the same folder.
You must never make any assumptions about the initial working directory for your application, as this will depend on what method was used to launch it (e.g. Finder, Terminal (via open), Xcode, gdb, third party utility, etc). You should use an appropriate API to find a suitable directory to store temporary files or user-specific files or whatever it is you need to do. This should never be within the app's bundle and never at a path that is relative to the initial working directory.
You do not want the file to be created inside the .app wrapper. That is never the right answer; your application may easily be installed somewhere where the current user does not have write access to the YourApp.app wrapper.
(For example, my main user account is non-admin and all applications are installed admin-write-only. If an app ever fails to work because it can't write to its app wrapper, the app goes in the trash.)
See this question for an outline of where files should be stored. Depends on the role of the file.