Re: Newbie Question - Hidden Password
Re: Newbie Question - Hidden Password
- Subject: Re: Newbie Question - Hidden Password
- From: JollyRoger <email@hidden>
- Date: Sat, 09 Jun 2001 15:51:12 -0500
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?
>
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.
>
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?
>
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?
>
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?
>
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.
>
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"?
JR