Hi,
Thank you very much for your detailed input. I understand most, but not
quite all...
> The parent property is read-only, so you can only assign its value when the
> script object is created (in this case, when your script is compiled).
OK, I'm glad I can close the door on the parent thing. Lots of hair-pulling
trying to get it to work, and my wife wants me to keep some of my hair.
> 1. Put any properties containing shared state into a library of their own.
What does this do? How is it an advantage?
> 2. Bind each library to a property in your main script.
Done.
> 3. Have your main script pass to each library a reference to each of the other
> libraries it uses. The library should bind each of those references to a
> property in itself. Now when one library needs to refer to another, it just
> refers to the appropriate property.
A little lost here, but I think this is where my program is suffering. I
gather from the last poster that one key to my problem is that when I load a
script file into a property I'm just getting a copy of it, not a reference
to the actual script (I had thought I was). So when I try to get the
contents of a variable in a loaded script, I get "0" because the variable
has no value in the COPY of the script file.
How do I pass a reference to the script(s) in such a way that I can bypass
this copying behavior and access the real script? Or can you please give me
an example of how I would use the method you mention in #1?
> Each script should refer only to things it contains, i.e. its own properties
> and handlers, and where a property contains a library, the script should refer
> to that library's top-level handlers only. (Note: while you can refer to a
> library's properties as well, it's better that you don't since such code will
> be harder to modify in future.) A script should never refer to things outside
> itself, nor to libraries that are nested within other libraries. Follow these
> rules and your problems will be solved.
For the most part this is covered in my app... The libraries are for the
most part groupings of handlers, and are self-sufficient.
The exception is where my problem has arisen... I have a complicated
"Export Settings" nib with various views. I decided to group everything
related to that nib in one script... This works perfectly until I go to
actually export, at which time I need to access the global list of records
in my main script.
The only way I could figure to do this was a "PassMasters" handler in my
main script that I could call from the export button. The only thing is
that if I attach the export button to my main script, then that button now
sees the loaded copy of the subScript, not the real one. The master list of
values passes fine, but I've lost the export settings.
> If you want, you could use AppleMods Loader system...
> ...Or you can roll your own without too much difficulty if
> there's not too much stuff to juggle.
I really want to stay away from my app being dependent on 3rd party stuff in
other locations on the user's drive if at all possible. If I can do it
without this, I would much prefer it.
> BTW, you can even pass libraries a reference to the main script if you really
> need to, though if you're doing that it's probably an indication of bad
> design. Circular dependencies are usually an indication of poor program
> structure, as is having large amounts of shared global state. Consider
> rethinking your program's structure to address this, as a program that's
> chock-full of complex interwoven dependencies will be difficult to develop,
> hard to debug well and a pain to maintain.
Note taken. I was starting to do this as I was trying to figure a way
around this problem... I will stay away!
> Also, a cautionary word: it's _much_ easier to construct an application in
> modular form when you design it to be modular from scratch than retro-engineer
> a large monolithic script into modular form. A good dependency graph should
> look more like a tree structure than a ball of yarn, and monolithic scripts
> tend to end up the latter. So expect to have to progressively rearrange and/or
> redesign various bits of code to eliminate knotty relationships before all the
> pieces will sit comfortably. I found out this the painful way the first time I
> tried to modularise a giant monolithic script for similar reasons. Taught me a
> lot about how _not_ to design big programs, that exercise did. :p Thereafter,
> I always designed and built big projects to be modular from scratch and have
> had no headaches since.
I wish I had known about the file size limit at the beginning! I read the
ASStudio documentation from cover to cover, and there was so little info on
splitting into multiple scripts... In contrast, almost all their
documentation and tutorials were based on single scripts, so that's the way
I went. Definitely learned my lesson!
I hope you get this soon, as I am really tied up until I can figure this
out, and I don't want to code in the wrong direction.
Thanks,
GJ
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-studio mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/applescript-studio/email@hidden
This email sent to email@hidden
