Dialog Director complexities [WAS: Re: Newbie Question - Hidden Password]
Dialog Director complexities [WAS: Re: Newbie Question - Hidden Password]
- Subject: Dialog Director complexities [WAS: Re: Newbie Question - Hidden Password]
- From: Paul Berkowitz <email@hidden>
- Date: Sat, 09 Jun 2001 15:05:00 -0700
On 6/9/01 1:51 PM, "JollyRoger" <email@hidden> wrote:
>
On 6/8/2001 10:52 PM, "Paul Berkowitz" <email@hidden> wrote:
>
>
> I've been looking into DD recently and wonder if those with more experience
>
> can answer a few questions.
>
>
Hey Paul, small world :)
>
>
I've been using it for two years, so maybe I can help?
Thanks. I was hoping you'd reply, JR.
>
>
> 1) Using live dialogs with 'dd install', I find that in OS 9.1/AS1.6, 'dd
>
> delete dialog' does not work well OMM. Instead of deleting the front dialog
>
> and letting the next one behind carry on normally, everything freezes with
>
> mostly-blank and unavailable dialogs and apps. Running 'dd uninstall' in a
>
> script editor is the only way to get out of the mess.
>
>
>
> The workaround I've used is to continually update the records which created
>
> the dialogs every time something is changed by 'dd set' or 'dd make'. Then I
>
> can get the various current bounds of dialogs beneath the top one, via 'dd
>
> get bounds', do a 'dd uninstall', a 'dd install' and recreate the lower
>
> dialogs according to the up-to-date records. It works, and recreates fast,
>
> albeit with a brief blip, but is there a better way? Does everyone have the
>
> freeze problem in OS 9.1 with 'dd delete dialog'?
>
>
I use DD a lot in two of my products. I generally have no more than 3
>
dialogs open at once. I always use dd delete <dialogRef> to close each one
>
when I am done with it.
>
>
Note that I use the dialog reference generated by dd make dialog:
>
>
set theDialog to dd make dialog dlog128
>
.
>
.
>
.
>
dd delete theDialog
>
>
I've had none of the problems you described. Are you saying that DD
>
sometimes does not delete the dialog you specify? Are you sure you are
>
specifying the correct dialogRef? Can you give me an example script so I
>
can see for myself? I may be able to help.
That's how I was deleting, with the dialog reference. I had two dialogs
only, and 'dd delete topDialog' did in fact delete the top (newest) dialog
as intended, but left a frozen mess when it disappeared. The part of the
lower dialog, and anything else that had been covered by the top dialog, is
blank gray, and everything except the cursor is "frozen" there. The cursor
could move so I could execute a 'dd uninstall' to get out of the mess. This
was using Script Debugger 2, Smile and running a compiled script in
Entourage. The same thing happened in all three. This is with Mac OS 9.1 /
CarbonLib 1.3.1. I was wondering if perhaps OS 9.0 or 9.1, or CarbonLib
1.3.1, introduced this problem for DD, which hasn't been updated since 1997.
Which OS and CarbonLib are you using? There have been some changes in the
window layering, perhaps.
>
>
> 2) I've found that keeping dialog records current is also necessary because
>
> there are so may instance where 'dd set' will not work (bounds -aside from
>
> push buttons and whole dialogs - , class, etc. It works fine for value and
>
> usually for contents of dialog items), and 'dd get' is mostly ineffectual.
>
>
Wait. Are you are trying to change positions and classes of dialog items
>
AFTER you've created the dialog? May I ask why? I can see changing say the
>
position of a button or something maybe, but why change a dialog items class
>
from a button into an edit field?
>
>
Instead of going through all that, have you considered just opening a new
>
dialog?
>
>
Am I misunderstanding what you are doing?
Nope. I'm doing something crazy, and incredibly complicated. I'm recreating
Entourage's Custom View dialogs which add and remove criteria, each one a
collection of 4 to 5 different dialog items: two to three popup menus, a
text field, sometimes some static text, and a "sticky polygon" to emulate
Entourage's focus box. Selecting certain popup items changes Popup 2 to a
text field or text field in position 3 to a popup, or removes two of the
items etc. Clicking in the sticky area enables the "Remove" push button.
Click the Remove button removes all these 5 linked items, some of which may
have been replacements for the original item in its location, etc. I found
that when removing (which also means altering the bounds of two group boxes
and two push buttons) it's actually infinitely smoother to remove all the
criteria and recreate the ones not being removed. All the records linking
the items which make up a single criterion have to be continually updated.
But when just replacing a single item it seems better just to replace that
one, not everything else. For the hell of it, I even recreated the "Choose
Folder" list box in a new dialog, if that option is clicked, and a "New
Folder" dialog if that option is clicked. These are the dialogs that needed
to be deleted. I'm deleting the main Edit Custom View dialog along with the
other two and recreating it because of the problem described. Since the top
dialog is flashing closed anyway, it doesn't seem too disruptive to remove
the bottom one and remake it. It takes a fraction of a second.
Why am I doing this? Because I'm attempting a script to print the Custom
View result lists, which is not possible in Entourage. Unfortunately,
getting the [simple object] results of custom views is not at present
scriptable, so I have to get the user to recreate the criteria (just once:
the script will store the criteria). A method of doing so by ordinary
dialogs might involve 350 of them since this is actually very complicated,
and the user would give up. So decided to learn DD to recreate the UI
version. Actually, I've done this part of the script now: my DD dialog with
28 or more dialog items (could be 78, I suppose, with 10 criteria) acts and
behaves just like the original Custom View dialog in all its complex glory,
aside from a few missing icons. Why is it crazy? Because I expect that in
the next version of Entourage, results of custom views may well be available
by applescript, so all this part would not be necessary! it's sure made me
respectful of the Entourage developers, I can tell you. Just the basic logic
of the thing, forgetting the DD issues, are very complex.
Now I'm working on the part of turning the DD results into AppleScript
commands. If I had to do a separate script command in a long if/else if
stream for each type of result (turning "From" "Contains" "string" into
'every message of folder id 23 whose display name of sender contains
"string" or address of sender contains "string"', for example) there would
probably be about 5000 permutations. Fortunately, I've found that far fewer
permutations, using actual strings made up of the string versions of the
component DD results, plus 'run script', will do the trick. Then I'll have
to learn VBA for Word tables in order to print the results. Crazy, as you
can see. Keeps me very busy. In the meantime, I may have become something of
a DD expert, I suppose, but I'd like to see if I missed some tricks along
the way. It's also crazy since DD won't work in OS X anyway and I, for one,
will be gradually moving to X.
>
>
> So 'dd delete' of a dialog item is necessary, then 'dd make' for its
>
> replacement if it's a different class of item or you want to move it -
>
> except that you _can_ set bounds of push buttons. Because deleting a dialog
>
> item removes it from the dialog's 'item' list and the dialog record's
>
> contents list, and pushes the index of all subsequent items up one, revising
>
> the dialog record is tricky.
>
>
Why refer to the dialogs by their ID? Why not refer to them by reference
>
like I do?
I do that. I meant the individual dialog _items_, which are referred to by
their current indexing of the dialog's "contents" list. Each time I have to
delete an item to replace it by another one, all the items further down the
list move up one, and the new item goes at the end of the "contents" list,
not where its deleted precursor lived. This is easy enough in the main
dialog record, but not at all easy in the separate records (or lists) I have
in order to keep to keep track of which 5 linked items make up an individual
criterion. Deleting one item from a criterion actually requires deleting and
remaking the sticky poly too or it covers up the other items when it's
clicked (oddly, making it after the other items with which it overlaps
removes the problem) so two items are removed and the two mew items
replacing them go at the end of the list, and have to have these new indices
recorded in the separate criterion records.
I bet you didn't want to know all this - I'm beginning to feel a little like
richard23 here. Well, here's a tip I discovered, in return: setting the
enabled of a sticky item to false when it's been clicked on doesn't actually
turn it off on the screen - it merely reverses its action, so that if you
then click it again it will now turn off. But immediately setting it to
false twice in succession DOES turn it off. Both these actions are very
handy, so I'm glad it works that way, even if not intended or documented.
(See what i mean about inadvertently becoming a DD expert?)
>
>
> What's much worse is if a set of dialog items belong together (perhaps their
>
> item indices are recorded in a separate script record), then that record is
>
> thrown out of kilter by a 'dd delete' and a 'dd make' which makes the new
>
> item
>
> at the end of the contents list. I've found an extremely intricate way to
>
> continually update my script records or lists, but wonder if anyone has found
>
> an easier workaround.
>
>
Yes, I can see how that might be a problem. But I have to ask again is it
>
really necessary that you modify the contents of the dialog rather than just
>
opening a new dialog?
Yup. See above. I could create the entire dialog anew, I suppose, but that
would be too disruptive on the screen, I think, where you're just expecting
one item like a popup to change: to suddenly see the whole thing disappear
and come back would be a bit of a shock. I might try it to see, however.
>
>
> 3) I'm about to try 'gauge' for a progress bar, but worry again about
>
> deleting it at the end.
>
>
Why should you have to delete just the gauge rather than the whole dialog.
>
I'm confused as to what you are having trouble with here.
The gauge will be running while waiting for the whole custom view to form
itself from all the multiple criteria selected, perhaps having to check all
10,000 messages and 2000 contacts someone has. But you're right: the dialog
can be deleted at this point. I hadn't got to actually trying this yet but
yes, you're perfectly correct. Good. Thanks.
>
>
> Does it run simultaneously with app events that it's meant to track?
>
>
Yes, I believe so. You need to update the gauge periodically with dd set
>
value, IIRC.
>
>
> It looks as if it will only work with repeat loops, not
>
> whose clauses for apps that implement the, which is a shame, as it then
>
> means everything has to go slower than otherwise. Any tips?
>
>
Sorry, I am unclear on the meaning of this sentence. Could you explain what
>
you mean by "whose clauses for apps that implement the"?
>
Bad typo. That should have read "whose clauses for apps that implement
them". Entourage implements 'whose' filters, which I can use for almost all
the criteria I need to filter (one exception: recipients). They are much,
much, faster than multiple repeat loops which would otherwise be needed. But
the gauge seems to work by incrementing a value one by one through a repeat
loop. To keep accurate pace with the search, I imagine you increment a
counter in tandem with the repeat loop variable, Since that might make it
much slower than using the whose clauses, I might just post a dialog that
says "Please wait" until the results are in. That would probably be a lot
faster, although would have to forego the progress bar. I've been trying to
figure out another way for keeping pace with the search by filter, but there
isn't any: there's no way of gauging the progress of a ;'whose' clause.
Whew. That's it.
--
Paul Berkowitz