GoDiagram 3.0

Just started using 3.0… I especially like the extended shape
usage.

Can I ask a favor… now that Go 3.0 is open for surgery, can GoUserFlags and GoUserObject be made part of all visual base classes (especially goShape) or is this a critical strategy in the design of base classes?

It will make the writing of custom “home brew” serialization routines and property editors easier and more efficient…

PS What is the status of 3.0 and anything more coming in its release.

PPS… Is this possible?.. (Rainy day in New Jersey and nothing else to do:)

Any chance of a Visual Object Builder where mostly static objects can be built very much by draging and dropping shapes, nodes, ect onto base object layers… and where properties and events set on a canvas or using a property editor?

I know that this is not easy but is it something feasible or am I not understanding GoDiagram fully.
For example, my app requires complex interactive part templates… very much like those found in Visio, very time consuming to build using execution code… If I could only “paint” them on a canvas first… maybe my dog (who said I am spending too much time with “GoDiagram” and not him) will stop telling me he’s thinking about moving in with the neighbors…

Thanks… :)
Joe Licata

Adding two more fields to every GoObject would add significant space to every object while hardly ever being used.

Providing some kind of visual node designer is on our list of goals for a future release. That’s part of the reason we have added the controls in Northwoods.Go.Draw.

However, the main difficulty in assembling such objects is getting the resizing behavior right. In other words, how to easily let the designer “implement” LayoutChildren in the desired manner.

If it were just a matter of manually positioning and sizing various GoObjects as children of an initially empty GoNode, it shouldn’t be too hard.

You might want to play with the new XML binding facility provided by GoXmlBindingTransformer. It basically lets you construct most of the common kinds of GoXmlTransformers without having to subclass them and implement overrides. You give up some flexibility and power, but it sure is a lot easier to understand and use. Most of the samples now use GoXmlBindingTransformer.

Thanks Walter, on first reading I missed the description of GoXmlBindingTransformer in the new GoDiagram 3.0 User Manual. I know that I can apply it and each time I think of a possible extension.

Re: the unfeasibly of UserFlags and/or UserObject fields in GoObject… it just means that as objects become visually complex with data related to surfaces there is no field that “users” can use as a common utility field that extends across the entire inheritance hierarchy… making for uncomfortable fixes like shadow hashtables that carry GoObject vs UserData links;

Looking at the total number of fields already in GoObject today at some version in the future will two more be costly?

Thanks

Joe

Well, adding two fields to GoObject would add 20% to the memory required for a minimal GoObject, or 14% to every minimal GoShape.

Could you store that (presumably temporary) information on each node or link?

Possibly I’m minimizing the effect on storage… it just provides a uniform means for accessing custom user data across ALL GoObjects via a GoObject subclass. Adding UserFlags and UserData to GoObject should not break any existing apps… Maybe when you are comfortable with memory economics in the future you can add it…

Thanks

Joe Licata

Sorry, we’re old school here, we still count bytes. We all cut our teeth on PDP-11s and VAXes where memory was measured in kilos, not gigas.

Do I detect some Maynard alumni? Great era!

Spitbrook Rd in Nashua. But yes… that’s the company.