UI Connections in Script Class

Hi Shane

As Stated above, its a barnd new ASOC project template, with no code in the newley added script file, other the script end script lines, and the newley added view xib file is as standard other than the blue cube object added, which is pointing to the empty of code new script class.

I’ve started this new standard ASOC project template to use as a test bed for this problem I’m struggling with, so that I can figure out what I need to do in the previously mentioned real project.

The only code added is in the AppDelegate script as listed below.

    on applicationWillFinishLaunching:aNotification
        my myClassScript's alloc()'s init()
    end applicationWillFinishLaunching:
    
    on applicationDidFinishLaunching:aNotification
        current application's NSBundle's loadNibNamed:("OtherView") owner:(me)
    end applicationDidFinishLaunching:

which initiates the newley added empty of code script class, and loads the newley added view xib file.

If I add a blue cube object in the project templates standard MainMenu.xib, ponting to the newley added script class, Xcode does not complain, but if you do the same thing in the newley added view xib file, Xcode does complain.

So in short I’m trying to figure out what the difference is between the standard MainMenu.xib file, and any newley added xib files.
And why you can add a reference to the AppDelegate script in any newley added xib files, but you can’t add the same type of reference to other script class files.

To duplicate this problem does not require any amount of code, you can simply start a new ASOC project, and add one new script class file, and one new view xib file.

Still scratching my head.

Regards Mark.

Correction Shane, the MainMenu xib also complains about the newley created script class object.

But you are able to add the AppDelegate script object to any xib file without complaint.

So what’s the difference between the AppDelegate script object, and any newley created script objects, that either the Interface builder or any xib file does not like.

Mark

OK update to earlier posts.

When I remove the xib file loading code.

current application’s NSBundle’s loadNibNamed:(“OtherView”) owner:(me)

Then the Error message about the unkown class does not appear any more.

But with the downside that I end up with a xib file with a custom view in it that can’t be used.
Because it hasn’t been loaded.

AAAHHHHH

Mark

We can’t answer that until you show us the code. And as I keep saying, it’s not that IB doesn’t like it – it’s that it can’t find it because it isn’t loaded.

the main XIB is specified in Info.plist, so it’s loaded automatically during the launch process.

Another problem could be that any custom object (blue cube) is instantiated implicitly as well.
Try to Implement the standard init method in the custom class “ which is also called automatically “ and load the XIB from there

As already stated Shane, there is no code to show, it’s an empty brand new ASOC project other than the two lines as listed above previously.

AppDelegate.

script AppDelegate
use AppleScript version "2.4"
use scripting additions
    
property parent : class "NSObject"
property myClassScript : current application's MyClassScript
	
-- IBOutlets
property theWindow : missing value
	
on applicationWillFinishLaunching:aNotification
    my myClassScript's alloc()'s init()
end applicationWillFinishLaunching:
    
on applicationDidFinishLaunching:aNotification
    current application's NSBundle's loadNibNamed:("OtherView") owner:(me)
end applicationDidFinishLaunching:
    
on applicationWillBecomeActive:aNotification

end applicationWillBecomeActive:
    
on applicationDidBecomeActive:aNotification
    
end applicationDidBecomeActive:
    
on applicationShouldTerminate:sender
    return current application's NSTerminateNow
end applicationShouldTerminate:
	
end script

The newley added script class.

script MyClassScript
use AppleScript version "2.4"
use scripting additions
    
property parent : class "NSObject"
    
end script

As you can see, it’s not a problem with any code written, it’s a problem with adding a reference to the MyClassScript class via a blue cube object in any xib file within the project.
You can add a reference to the AppDelegate script class within any xib file in the project. but not any newley created script class’s.

Yes Stefan I did try adding an “on init()” method to the new script class, and loading the xib file from their, but you still get the same error message about unknown script class.
Yes I did check out the info.plist file and could see that the MainMenu xib is loaded automatically on application start up.
and according to the developer docs, you load any new xib’s with either the NSBundle’s methods, or NSNib’s methods.

How I see it is, how do you make the blue cube script object reference acceptable in the xib file, in the same way as the AppDelegate script reference is.
And on that one, I just can’t figure it out the difference.

It’s also worth me re mentioning, that you don’t even have to add any new xib’s, the new script object is equally unwelcomed in the MainMenu xib file as well.

Regards Mark

Actually you don’t need a custom object (blue cube).
Make the XIB a subclass of NSViewController and MyClassScript a subclass of NSView.
Then set the class of the view to MyClassScript and you have access to all properties of the view.
The view itself is connected to property view of NSViewController

You can load the controller with

set otherViewController to current application's NSViewController's alloc()'s initWithNibName:("OtherView") bundle:(missing value)
set otherView to otherViewController's view()

Mark, I’m really not asking just to annoy you…

No, that’s incorrect. Because of the way AppleScript treats case, you should probably use a different name. But more importantly, the property should be set to missing value. You’re making the connection to the class in Interface Builder, so you need an outlet.

But I’m confused. If I open your script as posted in a script editor, that line doesn’t even compile – it would have to be something like property myClassScript : current application’s class “MyClassScript”.

As an aside for anyone following along, the practice of defining properties as references to classes is best avoided. Apart from anything else, it causes problems if you try doing it outside Xcode.

Hi Shane.

I know your not trying to be being pedantic, but I did post the only code changes to the new ASOC project previously, I think you misunderstood, this project with the MyClassScript is just a test project, the larger more comprehensive app I’m creating does not use this named script, the script classes in the proper app I’m working on are named totally different.
This MyClassScript is just a quick testing process, for the blue cube reference issue.
In the larger app project their are several scripts that need to be initiated and used immediately upon the App starting, so in setting them to missing value, I would then need to reset them straight away to the current application’s scriptClassNames, so I decided to make them point to their respective scripts in the propertry declaration.
I’ve not had a problem with this technique, and they do compile and work as expected when using Xcode, I’ve not tried it in AppleScript Editor, and in all honesty, I don’t really need to.
The other thing about the real app project is, that all of the other script class files are purely functional, where their methods are called by the AppDelegate, and they return analyised sorted and formatted data to the AppDelegate, and from there the AppDelegate displays this data in various Text Views and Text Fields, I was simply trying to find a way for these functional scripts to update the UI display themselves, rather than sending the data back to the AppDelegate to display.
So I was simply asking why the blue cube script reference system that the AppDelegate uses, does not work with any other scripts.
And thanks for all your help.

Hi Stefan.

Thanks for that, it did occure to me to sublclass NSView, but I’ve always found subclassing a bit of ovekill when your only just trying to access IBOutlet properties, the original project I wanted to use the technique with, may have as many as six different views, so a lot of subclasing will be required.
But because I’ve not found any other simple way to access UI components form new script classes, I will probably have to use this method, so thanks for showing the best way to implement this.

I would still desperately loved to know why new script class’s are not accepted by a xib file, when the AppDelegate which at the end of the day is just a script, is accepted in xib files, it’s very odd.

Many Thanks

Regards Mark

It’s not overkill, to add functionality like custom UI elements and properties you have to subclass NSView and it’s the recommended way

I know what your saying Stefan, but in essence, I’m not trying to create custom view objects, I was just trying to access standard UI objects in a xib file.
I’ve always associated subclassing with giving standard Cocoa classes functionality that they don’t already have, in my case I was happy with unmodified standard UI Objects, but I just wanted a simple way to access them in code from a script.
The blue cube class reference technique, is about as simple as it gets, and I was trying to find out why this method does not work with new script classes.

I’ll probably be using the subclassing process you highlighted, while at the same time still being frustrated with not knowing why the blue cube method does not work as you would expect.

Thanks Again

Mark

the app delegate script is a subclass of NSObject, you add custom functionality by accessing standard UI elements.
What is the difference?

I guess the blue cube way does not work because the contents of the XIB must be ready to be used before instantiating the script.
NSApplication does that automatically for the main XIB specified in Info.plist

PS: To manage multiple views in one XIB you can also subclass NSViewController to add properties for the views

Yes it’s the same kind of conclusion that i’ve come to Stefan while I’ve been experimenting with this issue.
I suppose I was thinking there may have been some kind of application wide setting that could have been made, maybe even in the info.plist file, or maybe in the build settings side of a project.
But sadly I hav’nt figured out if it’s at all possible, so for the time being we’ll have to go the more long winded subclassing route.

Yes I was aware that you can have many different windows and views in the same xib file, in fact that was they way I was doing it originally, but as my project got larger, and I started having to add more views, the xib file become a bit cluttered and un manageable, so that’s when I started to try and break it down into more manageable size pieces.
After all, that’s part of the concept behind the object orientated programming principles.

Thanks again for your help.

Mark

You’re missing the point. Setting them to missing value and making connections in IB means you are dealing with a connected instance. Using properties like you claim means you’re dealing in the class. And classes can’t have connections, by definition.

Stop thinking scripts – they’re not really scripts, they’re classes that can be instantiated into objects.

Your sample code does not compile. I have no doubt your project does, but that just means your sample doesn’t reflect what you are really doing.

That sounds like you’re calling their handlers as class methods. That’s fine – but classes can’t have connections.

Shane

I’m telling you that the code I posted compiles for me just fine in Xcode, if your testing the code in another editor, then to be frank, I could care less if it does not work in your other editor, it’s an Xcode project, and as long as Xcode is not complaining, then that’s good enough for me.
It sounds like your suggesting I’m being dishonest, I’m a lot of things, but a liar is not one of them.

When I post or answer questions in developer forums, I always hope that they are dealt with in a helpful manner, and in return, I always try and take that approach myself when replying to others, but in this case I’ve only found you to be critical rather than helpful, criticism does not help anyone, so please feel free Shane not to reply to any future posts I make in these forums, if indeed after reading your replies I even bother to post in the future.

Stefan I was grateful for your help and advise, and your Knowledge is dispensed in a friendly and informative way, so many thanks for that.

To all, please consider this forum post to be concluded and finished.

Mark

Please calm down Mark, there is no reason to be pissed off.
Shane’s posts are always as “friendly and informative” as other’s.
He knows much more about AppleScriptObjC than anybody else

Xcode is a very complex application and can behave differently under certain circumstances like different system versions, Xcode versions, custom preferences and much more.

Hi Stefan

I do recent someone implying I’m somehow dishonest.
Why on earth would I need to be ?

I’m well aware of Shanes knowledge and experience, along with yourself and a few other regular contributors in these forums, and I’ve learnt alot form yourself and others around here.
But knowing alot about a subject, does not always mean that the knowledgable person makes a good teacher, and you can take my word for that, as I’ve done a lot of teaching through my life.
being a good teacher takes patience and understanding.
Unfortunatly I’ve never been a big fan of Shane’s attitude toward some posters in the past, and I find his approach a bit blunt and aggresive on occasions, but that’s not to say all of the time.
His last post to me I found rude, and for that reason, I choose not to want to learn of someone like that, even if they are knowledgable.

For that reason also I would like to move on from this particular forum posting, and I’ll be trying my hardest not to have to post in the future, and try to resolve my coding problems on my own.

Thanks Again Stefan.

Regards Mark

Not at all! It’s just something that is easy to do – in simplifying code to post, it’s easy to make changes that won’t really work. I’ve seen it happen regularly, and I’ve done it myself.

In fact, you are correct that Xcode will compile the sample, so that issue is a red herring. However, it still sounds like you’re confusing classes and instances.

I’m sorry if you find my approach too blunt. If it seems at times I lack patience, it’s usually because I’m short of time.

I did not just find your response blunt, I found it insulting.
Who do you think you are, that you have the right to pass judgement on peoples character of whome you know nothing.

Were all busy people with not enoough time on our hands, that’s not an excuse for being rude.

As far as your opinion of my programming issue, I know longer value your opinion, and have stopped caring what you think some time ago, so please feel free to not offer any more opinions to me personally, as struggling to find my own solution is now more prefrable, than being talked to in a condescending tone.

I would have more respect for you Shane, if you admitted you spoke out of turn, and offered a simple apology.
But if thats not in your nature, then please dont bother posting anything else in response, and consider this forum posting finished.

Mark