Changes in 2.3

Discussions concerning general integration topics.

Moderator: Phil Barton

Post Reply
roteague
Posts: 292
Joined: Thu Sep 25, 2008 4:49 pm
Location: Honolulu, Hawaii

Changes in 2.3

Post by roteague »

Where can I find all the changes that have been put into 2.3?

After installing 2.3, and recompiling various projects I get a lot of errors. For example:

1.) LookupValue - Overload resolution fails because no 'New' is accessible
2.) IPrintDispatchHandler is not defined
3.) ProvidePrintDispatchHandler is not defined
4.) GetProperty is not a member of SnapSectionBase
5.) "Close" is not a member of SoftPro.Select.Shell.ToolWindowPane.

What other issues are we going to run into?
Robert
Hadi Chemaly

Re: Changes in 2.3

Post by Hadi Chemaly »

The following are change descriptions that will help you resolve the issues you listed in your post:

I can't guarantee that (1) will solve your compile time error, but it is a statement of changes that went in the lookup API. ==>

1. Instead of returning a straight DataTable, we now return a custom LookupDataTable that inherits from DataTable. The only real way this differs from a straight DataTable is that it overrides NewRowFromBuilder(). It does this so that it can create a new row with a new Guid for the ID, and empty LookupValue objects as the other fields. This was done to allow new rows to be added via the DataGridView.
If this does not fix your issue, can we get more details about what you are trying to do so that we can assist with your compile error? A code sample would be great.

Changes (2) and (3) came about due to confusion in the field about integrating with our original pipeline handler implementation. ==>

2. IPrintDispatchHandler has been replaced with the IPrintJobHandler interface that has (the same) Initialize method and a new Process method to replace the old HandleDispatched method. The only real difference is that the new method requires that an enumeration value be returned instead of true/false to dictate how the pipeline should proceed. In the past, the pipeline could only be stopped or allowed to continue based on the return value, but now we also provide the ability to resume at the start of the next stage in the pipeline.

3. The ProvidePrintDispatchHandler package attribute has been renamed to ProvidePrintJobHandler to coincide with the change in #2. The registration of print job handlers has been enhanced to support naming and enabling/disabling. Note that the overloaded constructor that takes no name parameter has been marked as Obsolete and may be removed in a future version.

4. I can't seem to understand what this error is about. SnapSectionBase does not appear to have had a public GetProperty method in any prior versions.

5. The Close() method was replaced with OnClose() for consistency; this is used for actions that need to be performed when the tool window closes. In addition, an OnDispose() method was added for clean up actions after the tool window has been disposed.

Please note that a 2.2 compiled package would not work in a 2.3 Client unless recompiled in 2.3, even if no API changes were made.
roteague
Posts: 292
Joined: Thu Sep 25, 2008 4:49 pm
Location: Honolulu, Hawaii

Re: Changes in 2.3

Post by roteague »

Hadi,

Thanks for your followup. I'm looking more to find out what the API changes were made, than how to solve the compile issues. The errors were examples of API changes breaking existing code. Had there been a release document, laying out the API changes, it would have been easier to track these issues down, rather than having to rely on compiler issues. Instead, it took a lot of time and effort to track down the changes, requiring architectural changes in some cases.

Thanks for your followup,
Robert
roteague
Posts: 292
Joined: Thu Sep 25, 2008 4:49 pm
Location: Honolulu, Hawaii

Re: Changes in 2.3

Post by roteague »

Here is another example, I just ran across:

System.ArgumentException was unhandled
Message="Unrecognized command line argument.\r\nParameter name: r"
Source="spregpkg"
ParamName="r"
StackTrace:
at SoftPro.Select.Shell.Registration.Program.ParseArgs()
at SoftPro.Select.Shell.Registration.Program.Main()
InnerException:

This has caused VisualStudio to crash on me twice now. I found the fix, but it should have been part of the release notes as well.
Robert
czentman
Posts: 157
Joined: Tue Dec 02, 2008 12:02 pm

Re: Changes in 2.3

Post by czentman »

Still having a problem with creating a new row in the lookups API. I used to have code as the following for creating a new row if the user's current row in the gridview is on the last row in the grid. It seems to have a problem with this code.

I tried looking for a lookupdatatable and couldn't find anywhere. Maybe I need to add another reference because it's not in the references that I have already. All this code worked in the previous version of 2.2.

Please help. Thanks

Using table As System.Data.DataTable = lookups.GetTable(cboLookupType.Text, spec)
Dim row As System.Data.DataRow
If DataGridView1.CurrentRow.Index = table.Rows.Count Then
row = table.NewRow()
row(0) = Guid.NewGuid()
dtabako
Posts: 1
Joined: Tue Feb 03, 2009 2:59 pm
Location: Raleigh, NC

Re: Changes in 2.3

Post by dtabako »

Hi,

Let me try to explain the changes in 2.3 in a little more detail. First, LookupDataTable is an internal construct - we still return a normal DataTable so that is what you will work with. All LookupDataTable does is override NewRowFromBuilder so that when you ask for a new row - either via a DataGridView or from a call to NewRow() - you will get back a DataRow that already contains a Guid (ID) value in the first field and empty LookupValue objects in all other fields. This allows a DataGridView to get back a new row with a unique ID field which allows the functionality that the user can just type data into the last row of the grid to start a new row. So the code you were using to manually add a new row to the DataTable when the user navigates to the last row of the grid should no longer be necessary in 2.3. On the other hand, the changes shouldn't have broken the code you described. It's still perfectly possible to create a new row manually, although you should not have to assign a Guid to the first field manually anymore as your new row should be returned to you preloaded with a new Guid. Again, though, it shouldn't break anything if you do - it should just reassign a new Guid. Can you tell me what exactly is happening? I have tested out your code sample here and it doesn't give me a problem.

Thanks,
Dennis Tabako
Software Developer
SoftPro
Dennis Tabako
Software Developer
SoftPro
Post Reply