I imagine this concept will be the same whether the sql statement is executed from the front end or the cursor is returned from a stored proc

I left joined credit cards to customers ( handling nulls and returning "NO CARD ON FILE") so there is a cardnumber field being returned in the cursor that I get with the stored proc

At debug time in me.customersbo1.currentview I can see the cardnumber column with data.

I looked in BO mapper and there doesn't look to be anyplace there to fake the BO into created a property (probably just as well as I assume it could not be updateable)  Thought a custom field prop would be the way to go but

Return Cardnumber gets the error that it must be declared - but I'm not sure what the syntax is to tell it the field will be in the cursor at runtime

( I do realize that if I add a custom prop in this way I will probably need to always be sure it is provided in each data access scenario.  Does that mean I should be creating a view on the back end so the field is present in the definition when the bizobj is mapped?  No problem, if that's the case but wanted to make sure there wasn't another trick I was missing as I might want to display something like this without having to create an updateable view on the back end)

TIA

Charles

I think I've got is

RETURN me.currentrow.item("orderpo")

seems to give me exactly what I want (I was trying something like that in the watch window earlier with me.currentview.item("orderpo") but of course now I see why that wouldn't work)

Found the right syntax by just searching around here on all the message re custom properties

This framework, this forum and this community ROCKS !!

Charles,

It looks like you got it going.  I didn't work this weekend so I wasn't out on the forum much.  But you did get it figured out.  Returning a field or column from a joined table is a must in the disconnected world.  So in order to interact with it, just create the custom property and then...as you discovered...call the Me.CurrentRow.Item("MyField") property on the return an you have it.  If you intend to bind this field to anything, you will need to override the GetCustomBindablePropertyDescriptors method and return a ReflectionPropertyDescriptor.  There are a ton of posts and docs regarding this, but if you get stuck just let me know.

I agree Thanks for your kind words...and thanks for your input, Edhy!  I know that Charles appreciated it!

Trent, thanks for the explanation.

Charles, I am glad you find it.  In fact I was not sure on the right answer since I have not done that yet, but I knew it has something to do with the return value of the custom field property, now I know

Edhy Rijo

Thanks to a some posts between Greg and Peter Jones I figured out the array and the sample in the tutorial make more sense

Once the project is rebuilt the field appears in the enumeration for binding field and displays just what I need.  Of course the field is read only, as it should be.

Charles,



Glad you got it going! Here are some other things to consider when using custom properties that will reference a "special" field in the data table:



- You probably should check for a current row...if there is no current row, the .Item("orderpo") will throw an exception



- You also probably need to handle the case were the column isn't in the table. I.e. what if you have a fill that doesn't include the "orderpo" column, you forget and reference it anyway...boom. You would just use a Try/Catch and throw an exception that will quickly let you know what you forgot.



Just a couple of things that I spent too much time on in the beginning, thought I'd share

Or just test on the count:

Trent, should one always test for the count in using customer field props, then? 

Honestly I only do this when there is the potential for this to occur.  If this should never occur based on my logic, then I don't do this so I get an error message preventing any other downstream errors.

Hi Greg

Thanks for the heads up.  in this case I'm joining to another table in the stored proc so I think there will always be a column.  Since I'm doing a left join, I'm testing for null in the initial select and returning a "NO PO NUMBER" string in the case of a null value.

This exercise was a reminder, however, to actually look at the test data before making ***-umptions about the results. (hey that's cool, I put in a hyphen to emphasize the old trope about assumptions and the parser censored me ) The ORDERS table in the Strataframe Sample Data is mostly blank in the or_ponumber field and I really suspected I was having a series of senior moments when I finally got the binding to work, did my thing to check nulls and still ended up with a blank textbox on the screen and a blank in the field in the currentview.  Thought I may have forgotten everything I knew about SQL. 

But of course I was getting just what I asked for - I just didn't know I'd asked for a column where most of the values were blank

I am going to test now to see if an exception is thrown if there is no data at all in the cursor as I'm starting to think the gist of your suggestion may be that custom props do not behave like bomapper props when the query pulls an empty recordset.