Field Codes and Reflection

[danvanf]

I am updated our Field Explorer for MS Word, to add the Glenwood fields. I'm attempting to use Reflection to gather this information and have a few questions, is SoftPro using Reflection to generate the Field Code Tool? (If not may I have some direction please?)

I’m running into some odd(to me) issues, let's take Order.Note.* for an example.
Trustee() is returned as a SoftPro.OrderTracking.Client.INote.Trustee
Since the Field Code tool doesn’t have Trustee listed, and it’s in the SDK Documentation as a property of the INote Interface, I’m guessing SP is not using reflection, but then again, my implementation of Reflection doesn’t return SortOrder() or ID(). I’m ok with not having ID, I don’t want it anyhow, but do you know why Trustee would be returned, and SortOrder would not?

I’m not comfortable enough in C# yet, so here is a Wildly shortened code sample of what I’m doing in VB.Net

Private asm As System.Reflection.Assembly
Private pi As PropertyInfo()
Private ty As Type

asm = System.Reflection.Assembly.LoadFrom(“Softpro.OrderTracking.Client.dll")
ty = asm.GetType(“Softpro.OrderTracking.Client.INote”)
pi = ty.GetProperties

Then pi contains a collection of PropertyInfo(), which I use to generate the list, and it’s cool cause now I know the type. But I don’t get SortOrder, or ID, and can’t figure out, if you’re using reflection, why you don’t show Trustee.

Just so you know, Code samples in C# are fine, I can follow along, just not quite code there yet.

Thanks!
DanV

[Phil Barton]

You are correct in that we do not use reflection to populate the field code browser. It uses a different means to determine which fields are available for display in the list. These fields translate into fields that are usable in formulas, documents, etc. The API, however, exposes more fields than are available in the field code browser. This is accomplished again through a different means than reflection.

As to the specific fields not showing when you use reflection to get the properties using the API interfaces, I used the following code against the latest version of the SoftPro.OrderTracking.Client.dll assembly and was able to retrieve the fields mentioned:

Code: Select all

Imports System.Diagnostics
Imports System.Reflection

Module Module1

	Sub Main()
		Dim asm As Assembly
		Dim ty As Type
		Dim pi As PropertyInfo()

		asm = Assembly.LoadFrom("SoftPro.OrderTracking.Client.dll")
		ty = asm.GetType("SoftPro.OrderTracking.Client.INote")
		pi = ty.GetProperties()

		For Each p In pi
			Debug.Print(p.Name() + ": " + p.PropertyType().Name())
		Next

	End Sub

End Module

The output I got was:

CreateDate: DateTime
LastModifiedBy: ITrustee
Trustee: ITrustee
IsInternal: Boolean
Content: String
IsLink: Boolean
SortOrder: Int32
ID: Guid

Ensure that you have the latest version of the SoftPro.OrderTracking.Client.dll assembly in the working directory of your application.

[danvanf]

Thanks for the quick response Phil!
My Softpro.OrderTracking.Client.Dll is 9/29/08 10:37AM, 1,044,480

I built a quick test using your example and it works fine, so I'll have to examine my actual code to see where the real issue is. However what I'm really going to need to figure out is what that "different means" is. <Smile>

So if I might ask, is it possible to generate an accurate field code list via the API?

Can you extrapolate on "different means"? ... Pretty please?

Thanks again,
Dan

[Phil Barton]

If you use reflection on the API interfaces, you should be able to get an accurate listing of available fields. However, it will be a listing that is larger than that which is shown in the Field Code Browser in the SoftPro Select application. The API interfaces contain all the field codes listed in the browser with the addition of other fields that were determined to be necessary for proper use of the API (i.e ID, SortOrder, Trustee, to name a few).

As to the "different means", we have an internal representation of the fields within the object model. This includes many additional properties about each field to include whether or not it is visible. We use this representation to code generate the API interfaces. Thus, with some exceptions as noted above, only those fields that are indicated to be visible and persistable are used to generate the API interface facades. There is no public access to this representation. Hope this helps.

[danvanf]

Yes it does help, it confirms a few things I've suspected for a few months. I'll be able to use Reflection to make an initial list, create a list of undesirable fields to remove, then adding missing things like Sellers SSN1 and SSN2 fields as well as dealing with how HudLine items work and likely some other non-reflected fields.
Thanks,
Dan Van Fleet