dept Work Item Rss Feed

Created Issue: ToolWindow code generation bug?

o0mpie — Fri, 24 Jul 2009 09:11:56 GMT

Hi all, I wil repost here what I have posted in Negm's blog to make sure you guys know about it:

Just one warning to dsleditor users out there. There is a bug in the dsl editor powertoy that may be tricky to find. I haven't checked if this is new in 1.1 or was already there in 1.0.

In ToolWindow.tt the Guid for the ToolWindow is placed on the BASE class. This causes regpkg for instance to use the System.Type.GUID property of the class to generate the registration file (wix in my case).

This Guid is not stable and can change when changing namespace of your class (as well as some other factors).
When, like me, you use custom installers this will cause a desynch between the registry entries your installers create and the ones that are needed. Symptom: your DslEditor ToolWindow will be shown as an empty grayed out window without a name or not show up at all when using the menu command.

I traced it back to the cause described above after debugging and receiving an 80004005 (when converted to a hex string) HResult from the FindToolWindow method (this is called in ModelingPackage.GetToolWindow).

Modifying ToolWindow.tt to place the GuidAttribute on the proper class will prevent this and stabilize the registry that makes your designer work.

Hope this helps some people out there who are like me banging their head into the wall trying to figure out why their editors stopped working...

Cheers,
Anton

COMMENTED ISSUE: Release M1 - Tested Configurations

Yogudada — Wed, 16 Apr 2008 03:13:53 GMT

The following platform configurations have been tested for this Release (M1) of the PowerToy:

Win2K3 (SP2), VS 2005, VSSDK4.0, GAX 1.2

Any others? Please leave a comment in this form: OS? (SP?), VS2005 (SP?), VSSDK?, GAX?

We currently want to support dev on Vista, Windows2003, and Win Xp.
We currently only support Visual Studio 2005, not Orcas!
Comments: ** Comment from web user: Yogudada **

Vista Ultimate, VS2005 (SP1), VSSDK4.0 GAX 1.4 - works

COMMENTED ISSUE: Release M1 - Tested Configurations

markgreene — Thu, 07 Jun 2007 02:05:59 GMT

The following platform configurations have been tested for this Release (M1) of the PowerToy: Win2K3 (SP2), VS 2005, VSSDK4.0, GAX 1.2 Any others? Please leave a comment in this form: OS? (SP?), VS2005 (SP?), VSSDK?, GAX? We currently want to support dev on Vista, Windows2003, and Win Xp. We currently only support Visual Studio 2005, not Orcas! Comments: ** Comment from web user: markgreene **

XP Pro, VS2005, VSSDK4.0, GAX 1.2 - works.

CLOSED FEATURE: Provide access to root modelelement from editor control

jezzsa — Sun, 27 May 2007 16:46:26 GMT

Need to give editor controls access to the root element of the current DSL in teh DocView from either toolwindow host or designer host. Can't rely on DocView, since Designer does not have one! Comments: Resolved with changeset 2779.

CLOSED ISSUE: INstalling Assemblies

jezzsa — Sun, 27 May 2007 16:46:26 GMT

Current setup is accidentally installing 2 extra dependencies to GAC, that should already be installed byVSSDK. These need excluding from setup project Comments: Resolved with changeset 2779.

CLOSED ISSUE: ToolWindow Management

jezzsa — Sun, 27 May 2007 16:46:23 GMT

Minor bug in OnDocumentWindowChanged() event in base class of ToolWindow, for when to hide a window and update DocView Comments: Resolved with changeset 2779.

CREATED FEATURE: View Configuration

jezzsa — Fri, 25 May 2007 17:23:57 GMT

Once we have defined the view definition process, it’s a case of displaying configuration of the host DSL domain model for view definition by DSL developer. In any case, a hierarchical view (tree-view with checkboxes and visual differentiation, and context menus) is required to manipulate this view. Current options explored are: * Hosting a tree-view forms control within a shape (plain or compartment) * Hosting an entire fixed domain model representing hierarchy, that mimics tree-view with graphic shapes and connectors that cannot be edited. * Implementing a tree-view in a (read-only) compartment list, using graphics to indicate hierarchy and checkbox state (reminiscent of building a tree-view from a listbox in early C++ days) Any of these options would present the configuration of a view we would desire at this stage.

CREATED FEATURE: View Definition

jezzsa — Fri, 25 May 2007 17:17:52 GMT

These are the Use Cases for defining Views, based on a host DSL domain model of any complexity. Hierarchical View ------------------- Objective Define a view that represents a sub-part of a domain model. Since a domain model is inherently hierarchical, it makes sense to want to define a view that includes domain classes rooted at some point in the hierarchy, containing multiple branches, and each branch terminating at a particular domain class in the hierarchy. Requirements * This kind of view will have a single root, and multiple branches, each branch with many levels and children. * Each branch would need termination, either defined explicitly by user, or implicitly at end of branch. * Each branch expose children domain classes, relationships and properties of each child and relationship. * In cases of 1-to-1 relationships, the user should be able to choose to ignore the intermediate relationship in the view. Use Experience * In the DSLEditor shape, the user chooses a domain class from the host DSL as the root class of the view -> The user is then presented with the entire domain model rooted at that class, showing its child relationships and domain classes in a hierarchical list (indented to indicate ancestry). This list would include items representing the embedding relationships, and potentially reference relationships. These relationships may be presented with visual difference. -> Each domain class and relationship would also expose each of its domain properties as a sub list item. -> Each domain class, relationship and domain property would be displayed with a checkbox (or similar UI cue) to allow user to select/deselect it. By default all classes and relationships are checked. * The user browses the list of (collapsed) items, and can expand/collapse and check/uncheck each checkbox. -> For domain properties this indicates whether to include the property of the domain class or relationship in the view with the domain class or relationship -> For domain classes or relationships, un-checking indicates the termination of that branch, indicating that the remaining branch is not included in view. * The user can chose to re-include a domain class or relationship by re-checking its checkbox, and this forces inclusion of all its ancestor items (which are unchecked if any in that branch) -> 0-to-1 or 1-to-1 relationships, can be indicated uniquely to user, these can then be skipped or omitted from the view for simplicity (perhaps context menu feature or Boolean property). Aspect View -------------- Objective Define a view that represents a single aspect of the host DSL domain model (i.e. security, state etc). Again it makes sense to want to define a view that includes domain classes rooted at some point in the hierarchy, containing multiple branches, and each branch terminating at a particular domain class in the hierarchy. The difference between this view type and the previous, is that these aspects are domain property centric. Not entirely sure if this view type is accounted for in previous view type. Reporting View -------------------- Objective Define a view that reports on one or more aspects of a view. The primary difference between this view type and previous, is that this view is primarily read-only, and totals, may somehow be included.

CREATED FEATURE: Provide access to root modelelement from editor control

jezzsa — Thu, 24 May 2007 19:04:42 GMT

Need to give editor controls access to the root element of the current DSL in teh DocView from either toolwindow host or designer host. Can't rely on DocView, since Designer does not have one!

CREATED ISSUE: INstalling Assemblies

jezzsa — Thu, 24 May 2007 04:19:50 GMT

Current setup is accidentally installing 2 extra dependencies to GAC, that should already be installed byVSSDK. These need excluding from setup project

CREATED ISSUE: ToolWindow Management

jezzsa — Thu, 24 May 2007 04:18:13 GMT

Minor bug in OnDocumentWindowChanged() event in base class of ToolWindow, for when to hide a window and update DocView

COMMENTED ISSUE: Release M1 - Tested Configurations

jezzsa — Tue, 22 May 2007 21:07:02 GMT

The following platform configurations have been tested for this Release (M1) of the PowerToy: Win2K3 (SP2), VS 2005, VSSDK4.0, GAX 1.2 Any others? Please leave a comment in this form: OS? (SP?), VS2005 (SP?), VSSDK?, GAX? We currently want to support dev on Vista, Windows2003, and Win Xp. We currently only support Visual Studio 2005, not Orcas! Comments: ** Comment from web user: jezzsa **

Vista (Ultimate), VS 2005 (SP1), VSSDK4.0, GAX 1.2 works OK

CREATED ISSUE: Deploy common developer used assemblies privately

jezzsa — Mon, 21 May 2007 10:55:46 GMT

Might be a good idea to deploy assemblies expected to be used (referenced) by developers to either 'Program Files' or 'Public Assemblies' folder. Need to consider DLL hell for Public Assemblies folder if we ever allow multiple versions of these assemblies in 'Public Assemblies' folder

CLOSED ISSUE: Problems executing on Vista

jezzsa — Sat, 19 May 2007 21:55:52 GMT

Vista, VS2005 (SP1), GAX(1.2) Not able to run recipes, get various TypeLoadExceptions for various Actions in Recipes.Common. Indications are dependencies on Vista. We are looking into why this is. Can anyone provide more information? i.e. fusion log info?

CLOSED TASK: Complete Wiki Release pages

jezzsa — Sat, 19 May 2007 21:55:13 GMT

Create documentation pages for release: Wiki: * M1 * M1_Use * M1_Design * M1_Customize * M1_Recipe_Add... * M1_Recipe_Remove... * Update wiki Homepage with new release info. * Update wiki Milestones page with new release info. Other: * Intro.htm (Guidance Packages)

CLOSED FEATURE: Prototype customization use cases

jezzsa — Sat, 19 May 2007 20:54:10 GMT

Write the expected customizations (configuration changes, partial classes for toolwindow and editors) Create Sample project and walkthrough (wiki page ReleaseM1_Customization) that detail each customization. (Ensure that the current code allows for these customizations) The following are expected (and supported customization cases): Commands: * Change global/DSL menu commands, (Icons and Text) (same as previous version) ToolWindow: * Change Title * Change Icon * Change ToolBar Orientation * Show Buttons in Horz orientation * Change window Location and Orientation (same as previous) * Activate specific editors based on current selection Views: * Adding/removingeditors * Caption, Icon and Control * Temporary definitions Editors: * Track selection changes (same as previous) * Provide selectable items (same as previous) PowerToy: * Moving install folder * Renaming, moving files, folders Comments: Resolved with changeset 2596.

COMMENTED TASK: Complete Wiki Release pages

jezzsa — Sat, 19 May 2007 20:54:09 GMT

COMMENTED TASK: Complete Wiki Release pages

jezzsa — Sat, 19 May 2007 10:55:02 GMT

CLOSED ISSUE: Milestone M1 (Pre-Release) - UAT

jezzsa — Sat, 19 May 2007 09:42:25 GMT

For those asked to review this pre-release: Please make your comments about the upcoming release (M1), by posting comments here.

CLOSED ISSUE: Ensure Font propagating from VS to editor controls

jezzsa — Thu, 17 May 2007 08:27:20 GMT

Must ensure we have correctly handled change in Font in VS, and propagate this change to all editors. Currently the ToolWindow Host and DocView host (should) handle this change, and should pass this change to Hostcontrol. Comments: Resolved with changeset 2518.