Hello, a trivial problem but I didn’t find an ASOC answer:
Giving a string “Card” and a loop integer k from 1 to 100, how do you get:
Card001
Card002
Card003
…
Card100
with leading zeroes?
I have the pure Applescript solution working, but of course if it could be possible to get it through NSString methods, smaller, faster, cheaper.
Thank you!
i seem to remember reading somewhere here on the forum that stringWithFormat doesn’t work in ASOC. it’s easy enough to do in Objective-C though. This method creates an array with Card001 to Card100 in it:
#import "Formatter.h"
@implementation Formatter
+(NSMutableArray *)format {
NSMutableArray *cards = [[NSMutableArray alloc]init];
for (int k=1; k<101; k++) {
[cards addObject:[NSString stringWithFormat:@"Card%03d",k]];
}
return cards;
}
@end
Ric
Exactly the sort of things which makes me regret to not be Objective-C capable. 
Thank you. One day, surely.
It’s not that it doesn’t work – it’s just that the scripting bridge converts AS integers and reals not to ints and floats but to NSValues, so you can’t use %d (or anything other than %@).
It’s still useful for logging stuff, though.
Shane,
Thanks for that clarification. So, is there any way to use it to do the 0 padding like I did in objC?
I couldn’t find any easy way to do this using cocoa methods in ASOC without resorting to some if-then clauses to test for the length of the number. In applescript, there is the concept of negative indexes that you can use to get the end of a string – is there something similar in cocoa methods? I couldn’t find one. A pretty simple way to make this array in an applescripty kind of way is:
set theArray to {}
repeat with c from 1 to 100
set numString to get text -3 thru -1 of ("00" & c)
set the end of theArray to "Card" & numString
end repeat
Ric
Not that I can see. I spent a bit of time seeing if I could come up with some workaround to include in Myriad Helpers, but got nowhere.
A number formatter would probably be the best bet.
Nope – you have to get the length.
That’s the sort of thing I’d use in this case. it’s not as if it’s going to be time-consuming.
Ok then, I keep my Applescript old trick. It’s true that it’s fast enough, even for large serial treatments.
Thank you!
If it is time consuming or processor intensive, you could write your own class in Objective-C. Use a ‘for in’ loop to step through the array and you then can use StringWithFormat to add the padding, then you can call the subroutine from ASOC, provide the array and it will return the data (very quickly). If interested, I could provide a working example for you. I just tackled this problem with my current app and would be happy to assist. Once you start working with Objective-C, it will help brake barriers between Objective-C, C and AppleScriptObjC. Plus there more example classes in Objective-C, and you can use those directly within any ASOC app.
One quick example: I recently needed a short delay (pause the thread) smaller than a second to display some data before loading the new data that was ready but too fast for the average human to read if it was loaded without a small delay. Found a command in C called usleep that sleeps in micro-seconds, all I needed were 250000 (equals 1/4 sec) as my process before it took about 3/4 of a second to run. I was able to write my own class for it that can be used in Objective-C or AppleScriptObjC.
FWIW, NSThread’s sleepForTimeInterval: could have saved you some work.
Thanks! 
Thanks for your offer, goodtime, I already have tempted by Objective-C, but I’m already a newbie in ASOC, and I suffer a lot ” coming back to programming after 10 years of complete inactivity in this domain. My first contact with XCode was two months ago, and I was completely lost in these “text view 1 of tab view 2 of window 1”. then I climbed in the train of ASOC with the help of Shane Stanley’s book, discovering the huge territories of the NeXT Step stuff. I was already lost in the 100 classes of the Think Pascal Class Library, you may imagine my feelings in front of Cocoa’s.
So to tell, I don’t feel ready for Objective-C, and I regret it, because you are speaking the same language as the libraries, you know what type of variable you send, and what type you get. And of course, XCode helps you more when you write your code or debug it.
The only two benefits I could get in learning Obj-C are subclassing and speed. But Cocoa’s delegate concept avoids in great part the subclassing, and speed is rarely needed, as I write lambda-user applications. Sometimes, when you have to verify a lot of texts, character by character, it sucks, that’s right.
I’ve been cooled down, at the times of CodeWarrior, by these C gurus which seemed to prove one can write half a line where other languages needed four, and adored things like std::remove_copy_if(s.begin(), s.end(), std::back_inserter(t), boost::bind(strchr, ss_gaps.c_str(), _1) != (char*)NULL);
So, as I said, I’m not ready, but thanks!
fiz,
Not a problem. I am by no means an expert on Objective-C (just really starting doing things from scratch with it this week. I had to for efficiency and memory issues while dealing with large nested XML files).
When you’re ready let me know.
That’s the greatest things about AppleScriptObjC. 90% of plain AppleScript works. This is great for users getting to know the new syntax. AppleScript users can fall back it and learn small parts of ObjC to manipulate the UI. You add ObjC code, Objective-C or even C and C++ code whenever you feel comfortable to fill in the blanks.
You can also subclass AppleScriptObjC scripts rather than using 1 super large AppDelegate script. But managing variables can be a little more work when doing so. I’ve learned to use NSNotifications to help tie separate IO delegates together with my main App Delegate. Also have some getter subclasses in my main app delegate that my subclasses can access at anytime. Had to also create some global properties that could be written when an instance method calls a class method and needs to write some info. Note: when using mutliple subclasses, not all properties are always writable that reside in the main app delegate’s script area. I found by experimenting that you can have a property live outside the script end script area and it acts more globally by when subclasses need to write to one. reading properties that live within the script delegate seem to be global by default though, but sometimes will always be their default values. I think this happens with an instance method accesses a class method, the class’s properties act read only and have their default values. So if the property is not part of a class (or is probably only apart of NSApplication or NSObject and is not inside any script but lives in the top part of the main app delegate, then those properties can act globally between instance and class methods that access them) You may never run into this unless you start doing things asynchronously like with NSConnection. This property bugaboo that I ran into even happened when all the instance and class methods were inside of the main App Delegate. Hope you don’t run into it. It can be puzzling. Using NSNotification and some getter methods along with some “global” properties help resolve my issues.
Cheers,
gt
goodtime,
I have an application which is like a procedural one (badly) written in a hi-level object language, with one looong unique script à la BASIC (just the GOSUB are missing) and with each passing moment I feel less comfortable with this idea. Like I wrote in another post, with ASOC I’ve always the feeling to force a square form into a round hole.
My application has died 10 years ago, just after I was rewriting it from pascal to object pascal, because my compiler didn’t generate code for PowerPC - and then it was the Intel, with its UNIX (=C) basis.
But if I wanted to rewrite my application in object-oriented language, it’s because it uses massively objects. And now I am just fighting with records, arrays, NSdictionaries, NSConcreteData and the not-so-equivalent-as-that Objective-c/Applescript languages. What I dreamed of was, for example (I don’t know what syntax would be in Obj-C):
object cardObject : NSObject {
NSInteger itsID;
NSString itsName;
method setID (NSInteger anID);
method setName (NSString aName);
}
object textualCardObject : cardObject {
NSTextView itsTextView;
}
And do in code:
aCard = new (textualCardObject);
aCard:setID (23);
aCard:setName (“untitled”);
aCard:setTextView (aTextView)
myCollection:addCard (aCard);
See? Something really object-oriented, with typed parameters, where you can separate units, one for each object type (or object “family”) where it becomes more easy to see where errors are located, or add layers on something reliable…
I’m convinced that Cocoa is a great thing and that ASOC is a chance to peek at it, but sometimes. I feel discouraged (maybe simply because I’m not a programmer, only an amateur)
Regards
I think you may have mis-interpreted my suggestion. I was not saying to re-write your entire program in Cocoa, but to use a cocoa subclass when doing things like looping through an NSMutableArray to change the padding etc. Just to use cocoa were it would might fit better than AppleScriptObjC. And call the cocoa subclass from AppleScriptObjC.
If you are worried about your current application dying, I don’t think Apple will abandon NeXT’s Cocoa.
I am kind of concerned that Apple has yet to provide any AppleScript Studio equivalent examples of AppleScriptObjC and that Apple Engineers to do not provide support for ASOC. That’s not saying that Apple will kill ASOC eventually, but they surely haven’t helped ASS developers much besides one short tech note.
That is one reason why I steered away from AppleScriptObjC. It was pretty frustrating learning a tiny piece at a time, that is until Shane’s book came out with some good examples and well written explanation written from a scripter’s point of view and did not harp much on OOP theory.
ASOC also does not run on PowerPC or anything older than 10.6. That’s another reason why I waited a year. Most of my users were still on 10.5 or 10.4. I just hope my new Studio replacement suits 99% of my users. If not, my next version will probably be in Cocoa.
I’m also in transition. I do like the simplicity of AppleScriptObjC but it has its plus’s and minus’. Though it can also possibily be the most powerful language as it can bridge AppleScript, Objective-C and other languages very cleanly, out of the box. And it allow the programmer to decide, should I do this simple task in AppleScript and use ASOC code were only necessary? And maybe later after my prototype is done, if I’m not happy with it, I can stir in some Cocoa or see if AppleScriptObjC code will help make things work better? That’s pretty powerful.
goodtime,
You’re perfectly right, ASOC is the best thing that could happen to an Applescripter, and of course gaining such a considerable improvement comes with a cost – which is in fact a very low cost. Writing a real application running on the last MacOS version AND keep our old “tell application “Finder” to make this” is a big wedding ” in fact, I’m surprised that Apple seems to have not realized what they give to us (in any case, this has not made ‹‹much noise!). and not to mention the XCode IDE, which is simply another planet as the Script Editor!
If I give you a handler which parses a string and analyze it char by char (a bit like a Finite State Automaton), can you tell me how to rewrite it in Objective-C? It takes:
on entry, an Applescript string
on return, an array of records (in fact, it fills a Table View at each encountered error)
and it really sucks (I’ve had to put a Progress Indicator to make the screen a little less dead).
Regards,
Have you tried NSScanner to accomplish this? I don’t know if this would work for you or not, it depends on what kind of errors you’re looking for. If NSScanner works, you should be able to do it in ASOC.
Ric
Mmmh. Seems to be another marvel of Cocoa.
I created a new topic on this.
Regards