Do I need my own flavor?

[Steven__]

I have a treeview, and I am trying to implement drag drop reordering of widgets (similar to style panel). These are some of the issues I am having a hard time understanding.

1. Is it necessary to implement my own flavor. Each node represents an xml element saved in memory of the plug-in and reordering the nodes will have to reorder the elements.
2. How do you get a unique number-letter combination for your own flavor, Is it something that needs to be registered, and why is it different for Windows and Mac
3. When reordering, should the changes to the widgets in treeview be done manually or should treeview be reset and refilled from the underlying xml structure. (However if full refresh is done, then the treeview will lose it status, resetting to all nodes closed?)

Thanks for any hints, helps or even sympathy

[Steven__]

Part 3 has been solved with ITreeViewMgr Interface. however more info on flavors is desperately needed

[Dirk Becker · Accepted solution]

1) own flavor? Yes, as you have your own data type and a separate model that will not be compatible for other DD targets.

You mention backing XML. As a rule of thumb, would a drag of your object into the structure view (XML sidebar of layout window) mean you instantiate some XMLElement over there? Would your palette accept a drag originating in structure view?

There are plenty examples if you search the SDK for CDataExchangeHandlerFor.

2) A good idea would be to reuse the ScriptID of the scripting class that matches your model.

If (probably not) you need an external flavor on Windows, use RegisterExternalFlavor to register your flavor by string.

3) Decouple the tree from your model. Do not strictly follow the examples, they are oversimplified. Read about lazy notifications (e.g. TreeLazyNotificationData) - these are used to postpone UI updates until they fit in.

Dirk

[Steven__]

Thanks Dirk

Dirk Becker wrote:

1) own flavor? Yes, as you have your own data type and a separate model that will not be compatible for other DD targets.

You mention backing XML. As a rule of thumb, would a drag of your object into the structure view (XML sidebar of layout window) mean you instantiate some XMLElement over there? Would your palette accept a drag originating in structure view?

There are plenty examples if you search the SDK for CDataExchangeHandlerFor.

The xml I am backing, isn't to be placed within the document, rather it's like a preference file and all I would have to pass in the flavor is a pointer to xml element. Which has me wondering, should I make my own interface to wrap pointer or can I use something like UIDDATA interface.

As a side note, I'm using an xml library called tinyxml http://sourceforge.net/projects/tinyxml/ and its going well, but was wondering if you or anyone has experience with it. I know that xerces is the more robust choice, but it was overkill for my needs.

Dirk Becker wrote:

2) A good idea would be to reuse the ScriptID of the scripting class that matches your model.

If (probably not) you need an external flavor on Windows, use RegisterExternalFlavor to register your flavor by string.

So your saying, we basically make it up, and hope no-one else used the same number or letters (that they also used their scriptID).

3) Decouple the tree from your model. Do not strictly follow the examples, they are oversimplified. Read about lazy notifications (e.g. TreeLazyNotificationData) - these are used to postpone UI updates until they fit in.

This I think the ITreeViewMgr class will do for me. Is that not correct.

Honestly you had me laughing when I saw the words over simplified in the context of treeview and drag-drop.

Thanks again

[Dirk Becker]

> should I make my own interface to wrap pointer?

The InDesign object model has its benefits.

> As a side note, I'm using ... tinyxml

When I have to parse XML I just implement ISAXContentHandler.

> So your saying, we basically make it up, and hope ...

You would still use the official page to allocate your ScriptID from the official registry, so it is at least a degree less "make it up".

> laughing when I saw the words over simplified

Ok, let's add "in that regard". On the other hand they also leave out too many things as exercise. It can be worse though, e.g. if you had to accept some well known external flavor out of a multitude of flavors in the same data object, where you have to compete with internal implementations for existing targets...

Dirk

[Steven__]

Thanks Dirk.

Flavor is only for use in my plugin, is it necessary to do something like this

#ifdef MACINTOSH      const PMFlavor kEventDragDropFlavor = 'pmev'; #endif #ifdef WINDOWS      const PMFlavor kEventDragDropFlavor = 0x105E; #endif

since PMFlavor seems to be a typedef of a uint32, and only for use in my application can I just do

const PMFlavor kEventDragDropFlavor = 100;

and do I need seperate stuff for mac and windows

Thanks for all input