XUI handling: read-only and linking a dialog to a document

[ptc-1787870]

Greetings Adepters,

I've been asked to play the role of a XUI developer in an upcoming reality
TV series.

While researching for this role, I encountered two problems:
(1) Sharing XUI dialogs when multiple users have access to a
custom/dialogs folder
(2) Keeping code linked to a specific instance of a dialog and document

Sharing XUI dialogs - Our Editor users are set up to use a shared custom
directory over a Windows file system. We use an embedded XUI control (e.g.
myDialog.xml). Unfortunately, when another user opens a document, the
second user gets a "read only" warning (presumably because myDialog.xml is
essentially opened by Editor already).

This issue is not related to embedded dialogs; JavaScript code called to
create the dialog will produce the same warning message (here's some
initialization code to demonstrate):

var xuiFile = get_custom_directory() + "/dialogs/myDialog.xml";
var xuiDoc = Application.openDocument(xuiFile);
var xuiwin = Application.createDialogFromFile(xuiFile);

The users would like to avoid this warning message. How do others work
around this issue?


Keeping code linked - When it comes to keeping events and code changes
linked, I don't have code to illustrate. Basically, a user opens Document
A and this spawns Dialog A. User decides that the information is similar
to something else and opens Document B, spawning Dialog B. Everything is
fine until the user goes back to Dialog A and starts making changes,
expecting those to happen on Document A.

Can anyone share any tricks in how they keep changes specific to Dialog A
linked to Document A?

Regards,
Jason

[steve.cuzner]

For the first item, I would try passing the OPEN_NLOCK or OPEN_RDONLY
flags to the openDocument method.

For the second item, I risk being voted off the island, but I think the
answer is to set the parent window (see window.setParent(Window parent)
to the Epic window associated with the dialog. You can then get the
document associated with the window and write to the proper document.

Steve

Jason.Aiken@jeppesen.com wrote:
> Greetings Adepters,
>
> I've been asked to play the role of a XUI developer in an upcoming reality
> TV series.
>
> While researching for this role, I encountered two problems:
> (1) Sharing XUI dialogs when multiple users have access to a
> custom/dialogs folder
> (2) Keeping code linked to a specific instance of a dialog and document
>
> Sharing XUI dialogs - Our Editor users are set up to use a shared custom
> directory over a Windows file system. We use an embedded XUI control (e.g.
> myDialog.xml). Unfortunately, when another user opens a document, the
> second user gets a "read only" warning (presumably because myDialog.xml is
> essentially opened by Editor already).
>
> This issue is not related to embedded dialogs; JavaScript code called to
> create the dialog will produce the same warning message (here's some
> initialization code to demonstrate):
>
> var xuiFile = get_custom_directory() + "/dialogs/myDialog.xml";
> var xuiDoc = Application.openDocument(xuiFile);
> var xuiwin = Application.createDialogFromFile(xuiFile);
>
> The users would like to avoid this warning message. How do others work
> around this issue?
>
>
> Keeping code linked - When it comes to keeping events and code changes
> linked, I don't have code to illustrate. Basically, a user opens Document
> A and this spawns Dialog A. User decides that the information is similar
> to something else and opens Document B, spawning Dialog B. Everything is
> fine until the user goes back to Dialog A and starts making changes,
> expecting those to happen on Document A.
>
> Can anyone share any tricks in how they keep changes specific to Dialog A
> linked to Document A?
>
> Regards,
> Jason
>
>
>

[ptc-933085]

I think Steve got it right on both problems, but I wanted to add one
thing to the first item. I think if you don't change it to the code
below you may end up with the same warning message being shown:

var xuiDoc = Application.openDocument(xuiFile);
var xuiwin = Application.createDialogFromDocument(xuiDoc);

Of course you will need to add the OPEN_NLOCK or OPEN_RDONLY flags to
the openDocument method like Steve said.

--
Brian Jensen

Kyoshinsha Co. Ltd.
brian@kik.co.jp
2-9-5 Morinomiya-chuo Chuo-ku
Osaka 540-0003 Japan
Tel: 81-6-6941-8881
Fax: 81-6-6941-1053


Steve Cuzner wrote:
> For the first item, I would try passing the OPEN_NLOCK or OPEN_RDONLY
flags to the openDocument method.
>
> For the second item, I risk being voted off the island, but I think
the answer is to set the parent window (see window.setParent(Window
parent) to the Epic window associated with the dialog. You can then get
the document associated with the window and write to the proper document.
>
> Steve
>
> Jason.Aiken@jeppesen.com wrote:
>> Greetings Adepters,
>>
>> I've been asked to play the role of a XUI developer in an upcoming
reality TV series.
>>
>> While researching for this role, I encountered two problems:
>> (1) Sharing XUI dialogs when multiple users have access to a
custom/dialogs folder
>> (2) Keeping code linked to a specific instance of a dialog and document
>>
>> Sharing XUI dialogs - Our Editor users are set up to use a shared
custom directory over a Windows file system. We use an embedded XUI
control (e.g. myDialog.xml). Unfortunately, when another user opens a
document, the second user gets a "read only" warning (presumably because
myDialog.xml is essentially opened by Editor already).
>>
>> This issue is not related to embedded dialogs; JavaScript code
called to create the dialog will produce the same warning message
(here's some initialization code to demonstrate):
>>
>> var xuiFile = get_custom_directory() + "/dialogs/myDialog.xml";
>> var xuiDoc = Application.openDocument(xuiFile);
>> var xuiwin = Application.createDialogFromFile(xuiFile);
>>
>> The users would like to avoid this warning message. How do others
work around this issue?
>>
>>
>> Keeping code linked - When it comes to keeping events and code
changes linked, I don't have code to illustrate. Basically, a user opens
Document A and this spawns Dialog A. User decides that the information
is similar to something else and opens Document B, spawning Dialog B.
Everything is fine until the user goes back to Dialog A and starts
making changes, expecting those to happen on Document A.
>>
>> Can anyone share any tricks in how they keep changes specific to
Dialog A linked to Document A?
>>
>> Regards,
>> Jason
>>

[ClayHelberg]

Hi Jason, et al.--

I think you can get around the first problem by just not calling openDocument() at all. If you use createDialogFromFile(), I don't think you need to open the document separately--createDialogFromFile() handles opening the document for you. We've used this approach in our code for quite a while now, and while I haven't tested it explicitly, we've never had a problem with multiple instances of the dialog colliding in the way you describe. Heck, I can even have two instances of the dialog open on the same machine, associated with different documents, and everything works nice and smoothly.

(Dunno if it matters, but just for the record, *everyone* in our shop gets a read-only copy of the XUI documents, because they're checked in under our source control system. No one gets the "read only" warning you describe, presumably because that's based on a separate locking mechanism specific to Epic, which I think is triggered by the openDocument() call.)

As for tying a XUI dialog to its correct document when multiple documents are open, the parent property is probably the canonical method for doing so. However, I find the methods for getting from a dialog to a view to a document and back again a bit tedious, so I do it a different way: when the dialog opens (usually in response to an event on the target document), I set the appdata attribute on the dialog document's <window> element to the target document ID. That way I always know where to find it when I need to look it up, with a simple dlgdoc.documentElement.getAttribute("appdata").

--Clay

[ptc-1787870]

Thanks Brian, Steve, and Clay for the tips. It all sounds so easy-peasy
lemon-squeezie. 😉

I saw that ACL has flags to assign properties when a document is opened; I
didn't realize we had some of those options here.

That createDialogFromFile() might work better, and having some explicit
direction beforehand is helpful. As Peg Hellyer instructed me back when I
was learning FOSI: "the sooner you code, the longer it takes."

It sounds like setting the parent may help keep a dialog linked to the
parent document. The appdata attribute approach also sounds pretty nifty.
Reminds me of a case where I'm storing some transitory information in an
invisible button label (how's that for weird?).

Regards,
Jason





"Helberg, Clay" <chelberg@spss.com>
09/05/2006 08:36 PM
Please respond to
<adepters@arbortext.com>


To
<adepters@arbortext.com>
cc

Subject
RE: XUI handling: read-only and linking a dialog to a document






Hi Jason, et al.--

I think you can get around the first problem by just not calling
openDocument() at all. If you use createDialogFromFile(), I don't think
you need to open the document separately--createDialogFromFile() handles
opening the document for you. We've used this approach in our code for
quite a while now, and while I haven't tested it explicitly, we've never
had a problem with multiple instances of the dialog colliding in the way
you describe. Heck, I can even have two instances of the dialog open on
the same machine, associated with different documents, and everything
works nice and smoothly.

(Dunno if it matters, but just for the record, *everyone* in our shop gets
a read-only copy of the XUI documents, because they're checked in under
our source control system. No one gets the "read only" warning you
describe, presumably because that's based on a separate locking mechanism
specific to Epic, which I think is triggered by the openDocument() call.)

As for tying a XUI dialog to its correct document when multiple documents
are open, the parent property is probably the canonical method for doing
so. However, I find the methods for getting from a dialog to a view to a
document and back again a bit tedious, so I do it a different way: when
the dialog opens (usually in response to an event on the target document),
I set the appdata attribute on the dialog document's <window> element to
the target document ID. That way I always know where to find it when I
need to look it up, with a simple
dlgdoc.documentElement.getAttribute("appdata").

--Clay