Fields which are designated to contain GUIDs (e.g. Component::ComponentId) will present a "New GUID" button when edited.
Additionally, all string fields can be replaced with a newly generated guid by pressing CTRL+G when the field is selected but the editor is not open. Most field editors also support CTRL+G.
Monday, August 18, 2008
Tips and Tricks Part 2 - Displaying the current file's path
Clicking on the filename tab will display the path of the loaded file in the status bar.
In the case of transforms, the status bar will display the transformation chain (base msi, and the sequence of transforms that have been applied). In this case, it will show the filenames only.
Alternatively, as with most applications, clicking File->Save As will ensure that the Open File dialog is in the folder of the current file.
In the case of transforms, the status bar will display the transformation chain (base msi, and the sequence of transforms that have been applied). In this case, it will show the filenames only.
Alternatively, as with most applications, clicking File->Save As will ensure that the Open File dialog is in the folder of the current file.
Friday, August 1, 2008
Tips and Tricks Part 1 - Edit tracking and undo
"Tricks and Tips" would just give the wrong impression.
InstEd supports viewing transforms (mst files) and highlights all the changes that the transform makes to the base msi.
Under the hood, this is implemented by loading all the tables of the base msi and all the tables of the transformed msi. Some magic within the underlying InstEd table structures then does diffing of each row/cell to determine whether and how they should be highlighted.
Eventually I got around to using the same code to diff between msi's. Instead of diffing the tables between a transform and a base msi (or chain of transforms applied to a base msi), InstEd can happily diff between two msi files. When an msi is open, select the menu option: Transform->Compare To...
This is a useful thing to do in many instances. For example, every new release of the InstEd msi is generated by copying the previous release, and then diffing it against the release before that so that I can see what fields I need to change (ProductCode, Upgrade table, etc).
(Note that InstEd won't cope very well (read "crash") with identically named tables that have different schemas... just yet.)
The next obvious step was to extend the diffing code so that an open msi that is being edited can be compared to itself.
This means that as edits are made to the file, they will be highlighted, based on the same logic as the transform diffing code. So, changed cells will be highlighted in green, deleted rows will be highlighted in yellow, tables that contain changes will be highlighted in green, and deleted tables will be highlighted in yellow.
This highlighting is great, but ultimately, the big advantage comes from the undo mechanism provided by this diffing code. The diffing code allows for "Revert to base...", which makes the selected item (cell or table) identical to that of the base msi.
Right clicking on a cell or table provides the "Revert to base.." option.
To revert one or more rows that have been deleted, copy the deleted rows (CTRL+SHIFT+C) and paste them back again (CTRL+SHIFT+V).
In this fashion a reasonably capable undo mechanism is available.
It's not the same as most undo implementations which use a chain of undo/redo commands, however in some ways it is more flexible. For example, it can immediately "revert to base" any given change without having to undo all the subsequent changes in the chain. However, it will only "revert to base". It can't revert to intermediate values. i.e. change it once, then change it again, and the first change is unrecoverable via this mechanism).
Note that another excellent undo mechanism is to close the file without saving.
If you think that this feature should be enabled by default (or selectable) so that when opening an msi, InstEd automatically diffs it against itself, post a comment.
InstEd supports viewing transforms (mst files) and highlights all the changes that the transform makes to the base msi.
Under the hood, this is implemented by loading all the tables of the base msi and all the tables of the transformed msi. Some magic within the underlying InstEd table structures then does diffing of each row/cell to determine whether and how they should be highlighted.
Eventually I got around to using the same code to diff between msi's. Instead of diffing the tables between a transform and a base msi (or chain of transforms applied to a base msi), InstEd can happily diff between two msi files. When an msi is open, select the menu option: Transform->Compare To...
This is a useful thing to do in many instances. For example, every new release of the InstEd msi is generated by copying the previous release, and then diffing it against the release before that so that I can see what fields I need to change (ProductCode, Upgrade table, etc).
(Note that InstEd won't cope very well (read "crash") with identically named tables that have different schemas... just yet.)
The next obvious step was to extend the diffing code so that an open msi that is being edited can be compared to itself.
This means that as edits are made to the file, they will be highlighted, based on the same logic as the transform diffing code. So, changed cells will be highlighted in green, deleted rows will be highlighted in yellow, tables that contain changes will be highlighted in green, and deleted tables will be highlighted in yellow.
This highlighting is great, but ultimately, the big advantage comes from the undo mechanism provided by this diffing code. The diffing code allows for "Revert to base...", which makes the selected item (cell or table) identical to that of the base msi.
Right clicking on a cell or table provides the "Revert to base.." option.
To revert one or more rows that have been deleted, copy the deleted rows (CTRL+SHIFT+C) and paste them back again (CTRL+SHIFT+V).
In this fashion a reasonably capable undo mechanism is available.
It's not the same as most undo implementations which use a chain of undo/redo commands, however in some ways it is more flexible. For example, it can immediately "revert to base" any given change without having to undo all the subsequent changes in the chain. However, it will only "revert to base". It can't revert to intermediate values. i.e. change it once, then change it again, and the first change is unrecoverable via this mechanism).
Note that another excellent undo mechanism is to close the file without saving.
If you think that this feature should be enabled by default (or selectable) so that when opening an msi, InstEd automatically diffs it against itself, post a comment.
Subscribe to:
Posts (Atom)