This seems like the closest match to the problem I was seeing. I have a tree on a modal dialog

which displays data from a dataset. When I cancelled the dialog, and subsequently redisplayed,

the view and data still hung around and the tree was still loaded.  Destroying the view, tree, or dialog

didn’t work.

 

The ugly fix that I came up with was to create an LzDataPointer that points to the dataset that I want

cleared –

 

var ptr = new LzDatapointer(this, {xpath: "somePath:/someTag"});

 

Then I created a close() method on the dialog and a method that clears a dataset of any of its data.  In

the close() method, I called super.close() (important because it’s modal and the LzModeManager gives

the mouse back).  Then I clear the dataset (that the tree relied on), then set the ‘rerunxpath’ attribute on the

dataset to true.

 

clearDataset(ptr);

ptr.setAttribute("rerunxpath", true);

 

When the dialog now comes up, the data had been reset and the tree is empty.

 

thanks,

Dave

 

 

-----Original Message-----
From: Jes Lefcourt [mailto:[EMAIL PROTECTED]]
Sent
:
Wednesday, June 07, 2006 1:35 AM
To: [email protected]
Subject: [Laszlo-user] View replication in opttree not destroying some views

 

Hello!

We've encountered an odd problem, and were hoping that someone might have some suggestions.  We have an opttree that replicates nodes from a dataset.  We then do frequent updates to the dataset, causing the opttree to redraw, reusing some of its replicated views.  We find that sometimes (all descriptions of nasty problems always have the word sometimes in them) some of the replicated views don't go away. 

 

For example, suppose I have a tree with nodes A, B, C, D, E.  I then remove D and E.  Sometimes (there it is again), the views for D and E don't get removed.  When this occurs, if we add nodes F and G to the dataset, the view then still shows A, B, C, D, E.  When it works properly, it shows A, B, C, F, G.

 

Unfortunately, I haven't gotten this to occur with a debug window open yet, so I don't know anything about the properties of those views (if they're still part of the replicated set, etc).  Some things I have noticed:

 

  - The zombie views always run from some point to the bottom of the list (for example, in the data above, they would never occur with just A, B or just C, D).

 

  - The zombie views are still bound to the data for the node, and still respond to any of the actions that a real view does (like the drag and drop that I've implemented).

 

  - When the datapath of the opttree is changed to point to a different location in the dataset - one that does not include the data for the zombie views - the zombies still hang out and are still bound to their original data.

 

Does anyone have any ideas?

 

Thanks!

 

- Jes

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Even though this company takes every precaution to ensure this email is virus-free, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

 

Protedyne Corporation, 1000 Day Hill Rd, Windsor, CT 06095, USA,

www.protedyne.com

 

_______________________________________________
Laszlo-user mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-user

Reply via email to