Re: migrating from 32bit to 64 bit can not run project
/jporter hardcore_programmer def showpage __ Aaaand that’s probably horribly mangled postscript; but you’ll have to forgive me, as I haven’t had to read it in years, and have never had to write it in earnest… But to answer your question… I’ve had all sorts of odd issues with migrating Xcode projects forwards over the years; so the first thing I would do is extract your source code files (including any xib/nib or other resource files) and rebuild the project, starting from a blank Cocoa Application template in Xcode. Remove any default-generated files like MyDocument.m, etc. Then, add back your source files and do a compile. Fix any warnings or errors; especially 64-bit warnings. Also, if you aren’t doing it already, don’t name your NSDocument subclass MyDocument - it will just lead to confusion should the Xcode template’s version somehow get included along with your code (which is my guess as to what is going on here). Oh, and was there a conversion to ARC involved? Is this an open-source project; or otherwise is there some way we could get a look at the project folder? Not having it in front of me makes troubleshooting it kinda hard… :-) > On Mar 2, 2016, at 11:40 PM, Julie Porter wrote: > > I mostly program in postscript, which I use for a general purpose language > and MIDI parsing. From time to time I make a little coca app when I need to > do interactive views or real world interaction. > > I have a working app that I wrote under 10.5 that makes a little framework, > where I can parse and display the data in a scalable scrollable window. This > app seems to run under 10.7 and Yosemite. Recently I discovered a bug that I > wanted to look at and possibly fix. > > The parseable file is binary and has a type of .cis. > > When I went to run the app in X code on my 10.7 machine It defaulted to a 64 > bit scheme which I did not create. When I attempt to run a blank window > appears. When I open one of my .cis files I get an exception in documents.m > in the function "(BOOL)readFromData:(NSData *)data ofType:(NSString > *)typeName error:(NSError **)outError" > > The program should be reading from the MyDocument class using the function > "(BOOL)readFromURL:(NSURL *)absoluteURL ofType:(NSString *)pTypeName > error:(NSError **)outError" > > I switched to the 10.5 32 bit scheme and the code runs, but all my .cis files > are grayed out and I can not open them. > > In clicking the little triangles on the folder views I see there are now > duplicates of things like main.m and there are more than one info-plist > files. Where did these come from? There are also duplicate xib files that > are the ones that seem stubs. The blank window that appears in 64bit mode > seems to be coming from one of these stubs. > > how do I get my little viewer program to open the files again? Do I need to > copy my old settings into the new XIB files? > > -julie > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/bdurbrow%40rattlesnakehillsoftworks.com > > This email sent to bdurb...@rattlesnakehillsoftworks.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
How to implement NSWindowRestoration protocol in Swift
In my OS X single-window application (not document-based), written using
storyboards in Swift 2, I implement the NSWindowRestoration protocol's static
function restoreWindowWithIdentifier(_:state:completionHandler). I have reached
the point where it is called when it is supposed to be called.
But now what do I do? I can't find any examples showing how to implement the
body of this function in Swift.
At first, when I tried to translate Objective-C examples into Swift, any
reference to the main window controller's 'window' property resulted in the
compile-time error "Instance member 'window' cannot be used on type
'MainWindowController'". Now I realize that I have to create an instance of the
restoration class first. So, this compiles and runs when I use
MainWindowController as the restoration class:
static func restoreWindowWithIdentifier(identifier: String, state: NSCoder,
completionHandler: (NSWindow?, NSError?) -> Void) {
let controller = MainWindowController()
var restoreWindow: NSWindow? = nil
if identifier == "MainWindow" {
restoreWindow = controller.window
}
completionHandler(restoreWindow, nil);
}
However, how do I fit this into the storyboard context? When I create an
instance of MainWindowController here, I seem to be bypassing the segues in the
storyboard. It occurs to me that maybe I should make AppDelegate the
restoration class, instead of MainWindowController. The documentation is
cryptic, even in the NSWindowRestoration.h header file comments. I'm thinking
that then I could just restore the previously encoded underlying data model
values and let the storyboard run by itself as usual. But it isn't clear to me
what will become of the temporary window controller. Or, in other words, how do
I find or create a valid window in this method, as the header file comments say
I should?
I'm having difficulty finding my way. All guidance appreciated.
--
Bill Cheeseman - wjcheese...@comcast.net
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How to implement NSWindowRestoration protocol in Swift
On Mar 3, 2016, at 05:27 , Bill Cheeseman wrote:
>
> I use MainWindowController as the restoration class:
>
>static func restoreWindowWithIdentifier(identifier: String, state:
> NSCoder, completionHandler: (NSWindow?, NSError?) -> Void) {
>let controller = MainWindowController()
>var restoreWindow: NSWindow? = nil
>if identifier == "MainWindow" {
>restoreWindow = controller.window
>}
>completionHandler(restoreWindow, nil);
>}
>
> However, how do I fit this into the storyboard context? When I create an
> instance of MainWindowController here, I seem to be bypassing the segues in
> the storyboard. It occurs to me that maybe I should make AppDelegate the
> restoration class, instead of MainWindowController. The documentation is
> cryptic, even in the NSWindowRestoration.h header file comments. I'm thinking
> that then I could just restore the previously encoded underlying data model
> values and let the storyboard run by itself as usual. But it isn't clear to
> me what will become of the temporary window controller. Or, in other words,
> how do I find or create a valid window in this method, as the header file
> comments say I should?
— There’s nothing wrong with using MainWindowController as your restoration
class (AFAIK), because the restoration method is a static func.
OTOH, there’s no particular reason, in *this* part of the restoration
mechanism, to tie restoration to the window controller at all. In a sense, the
window controller has nothing to do with it, except to the extent that the
timing of its instantiation determines the time of window loading.
There may be other reasons to tie restoration to the window controller. I’ll
come back to that point later.
— Ignoring the rest of your app for a moment, if you’re using a storyboard then
creating a naked MainWindowController here is the wrong thing to do. Instead,
instantiate a MainWindowController from the storyboard in the “usual” way:
> let storyboard = NSStoryboard (name: "MainStoryboard", bundle: nil)
> let controller = storyboard.instantiateControllerWithIdentifier (“Main
> Window Controller") as! MainWindowController
This isn’t a *temporary* window controller, it’s the real thing. That means the
next step is to store the window controller reference wherever your app
normally keeps that reference: perhaps as a property of the app delegate.
Lastly, you invoke the completion handler to complete the window restoration
process (the controller.window reference causing the window to be loaded as
usual).
— But you need to be aware of what the rest of your app is doing at startup. If
your ‘main’ function instantiates the window controller unconditionally, then
you don’t want to instantiate a second one. You have a couple of choices of
what to do. You can go ahead and create it as you do now, then have your state
restoration static func *find* the window and initiate restoration on that.
(That’s what the header file comment "It is acceptable to invoke the completion
handler with a pre-existing window…” means: legacy code might have created the
window already, and you might wish not to change that.) Your restoration method
wouldn’t actually create anything in that case.
In these circumstances, it might indeed make sense to use the app delegate as
the restoration class, especially if it’s storing a pointer to the window
controller privately anyway.
Or you can remove that initial instantiation, leave the controller
instantiation in the state restoration static func as above, check (in
application didFinishLaunching) to see if a window controller exists due to
state restoration, and create it if not. This sounds like an excess of trouble,
but it’s what you’d do if you want to get to state restoration *before* the
window was actually loaded, for example if you wanted to create one of a number
of different NSWindow subclasses depending on state.
— Back to window controllers. If you have no custom state restoration, I think
I’d put the state restoration code in the app delegate and be done with it.
Looking back at the code in an old project, I see that’s what I did with the
preferences window, even though it’s document-based application. In the app
delegate (Obj-C because it’s old):
> NSWindow* window = nil;
>
> if ([identifier isEqualToString: @"GRAPreferencesWin"])
> window = [GRAPrefWinController sharedWindowController].window;
> // creates the window controller if it does not exist
>
> completionHandler (window, nil);
However, if you do have custom state restoration, then I think it’s easier to
put methods like encodeRestorableStateWithCoder and restoreStateWithCoder in
the window controller, since there is going to be a custom class anyway.
Otherwise, you’d have to subclass NSWindow, and put what I think of as
controller logic in the window instead of the controller.
In *this* co
Re: How to implement NSWindowRestoration protocol in Swift
> On Mar 3, 2016, at 1:32 PM, Quincey Morris > wrote: > > — There’s nothing wrong with using MainWindowController as your restoration > class (AFAIK), because the restoration method is a static func. > > OTOH, there’s no particular reason, in *this* part of the restoration > mechanism, to tie restoration to the window controller at all. In a sense, > the window controller has nothing to do with it, except to the extent that > the timing of its instantiation determines the time of window loading. > > There may be other reasons to tie restoration to the window controller. I’ll > come back to that point later Quincey, that was very helpful and thought-provoking. It will take me a day or so to digest and play with it, but you have opened my eyes to more of the workings of state restoration. Thanks. If I come to any useful conclusions, I'll report back. -- Bill Cheeseman - wjcheese...@comcast.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Staggering new windows
This new Xcode project (with storyboards) makes new windows at the same coordinates, on top of each other. Just the ever increasing shadow gives that behavior away. Is there a way to (automatically) get that old Mac behavior of staggered windows? I think it was 20 pixels down and right. Sent from my iPhone ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Staggering new windows
> On Mar 3, 2016, at 2:46 PM, Daryle Walker wrote: > > This new Xcode project (with storyboards) makes new windows at the same > coordinates, on top of each other. Just the ever increasing shadow gives that > behavior away. Is there a way to (automatically) get that old Mac behavior of > staggered windows? I think it was 20 pixels down and right. Window Cascading: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/WinPanel/Tasks/SizingPlacingWindows.html -- Seth Willits ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: migrating from 32bit to 64 bit can not run project
On 3/3/16 12:00 PM, Britt Durbrow wrote: Britt; thanks for the quick reply. I deleted everything from the folder that I did not create, then stripped them from the project. This allowed the 10.5 version to find the right plist. I then did a copy on the build target, which I renamed, then changed the results to 64 bit and the program also built the second target. On the 10.10 machine I copied the working project folder. It took a bit of fiddling to get Xcode 7.1 to find the right settings. Once I did it built and ran. I fixed the bug. The 64 bit version is much faster. These files can be 100s of megabytes in size, They open much faster now. As for the naming of the NSDocument subclass. I pretty much rely on online tutorials. Not sure what ARC is. The project is open source (and open hardware) it has been around for over a decade on some obscure websites that deal with converting paper piano rolls to playable music (MIDI) I suppose I should upload it to my github account. (sheepdoll) I mostly have some quicklook (coverflow) plugins there as well as some embedded stuff. The hardware side of things is on iammp.org and mmdigest.comGallery/Tech under "USB Controller for CIS Optical Roll Reader" It is sort of an early Arduino (AVR 8bit) but with a parallel FIFO rather than a serial one. Currently I use a different OS to read the data to a SD card. Then do the postscript stuff under X11. It has been like hitting a moving target, to get all of this to work under OSX. I literally wasted years as some of the code was written as far back as OS7 (remember Quicktime MIDI architecture?) -julie But to answer your question… I’ve had all sorts of odd issues with migrating Xcode projects forwards over the years; so the first thing I would do is extract your source code files (including any xib/nib or other resource files) and rebuild the project, starting from a blank Cocoa Application template in Xcode. Remove any default-generated files like MyDocument.m, etc. Then, add back your source files and do a compile. Fix any warnings or errors; especially 64-bit warnings. Also, if you aren’t doing it already, don’t name your NSDocument subclass MyDocument - it will just lead to confusion should the Xcode template’s version somehow get included along with your code (which is my guess as to what is going on here). Oh, and was there a conversion to ARC involved? Is this an open-source project; or otherwise is there some way we could get a look at the project folder? Not having it in front of me makes troubleshooting it kinda hard… :-) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
