What is a Progress.data.DummyRow and how to use it.

The DummyRow is really an internal class used by the ProBindingSource.  It was not meant to be used by the application.

As its name implies, it has no real data in it.  It is just a stand-in on the .NET side for the real temp-table row.  Though it does have an Index property which is the row #.  

Where are you when you get this Appointment/DummyRow object?  I.e., you must be in some event handler.  If the Appointment correlates to the currently selected item in the Scheduler, and therefore it corresponds to the Position property of the BindingSource you are using, then the ABL buffer associated with the bound query should already contain the temp-table record for this Appointment.  So you don't have to find anything, it will just be there.

If this is not the circumstance, you can use the row # to REPOSITION-TO_ROW(row-index) on the query.  I would think that Telerik would give you the row # as part of the arguments to whatever event handler you are in.  If it doesn't then you could get it from the DummyRow using the Index property.  Be aware that this index is 0-based.

I answered this 10 minutes ago and then my answer disappeared.  Did you get it?

This was the answer of Laura :

The DummyRow is really an internal class used by the ProBindingSource.  It was not meant to be used by the application.

As its name implies, it has no real data in it.  It is just a stand-in on the .NET side for the real temp-table row.  Though it does have an Index property which is the row #.  

Where are you when you get this Appointment/DummyRow object?  I.e., you must be in some event handler.  If the Appointment correlates to the currently selected item in the Scheduler, and therefore it corresponds to the Position property of the BindingSource you are using, then the ABL buffer associated with the bound query should already contain the temp-table record for this Appointment.  So you don't have to find anything, it will just be there.

If this is not the circumstance, you can use the row # to REPOSITION-TO_ROW(row-index) on the query.  I would think that Telerik would give you the row # as part of the arguments to whatever event handler you are in.  If it doesn't then you could get it from the DummyRow using the Index property.  Be aware that this index is 0-based.

Thank you!

I saw Laura's answer as email but the link leads to an empty page. Thanks

Maybe it can be added to http://knowledgebase.progress.com/articles/Article/000040170

some code fragments contains a workaround based on Laura's answer. Still looking for a less undocumented way to get to the data

method private void radScheduler1_AppointmentFormatting( input sender as System.Object, input e as Telerik.WinControls.UI.SchedulerAppointmentEventArgs ):

        define variable lTTHandle as handle no-undo.
        define buffer lb-ttAppointments for ttAppointments.
        lTTHandle = buffer lb-ttAppointments:handle.
        getTtForAppointment(cast(e:Appointment, Telerik.WinControls.UI.Appointment), lTTHandle).
end method.

    method public void getTtForAppointment(iApp as Appointment,  iTTHandle as handle ):
/*
        appointmentMappingInfo1:Description = "ART-CODE".
        appointmentMappingInfo1:End = "WO-END".
        appointmentMappingInfo1:ResourceId = "RES-ID".
        appointmentMappingInfo1:Resources = "ttAppointmentResources".
        appointmentMappingInfo1:Start = "WO-START".
        appointmentMappingInfo1:Summary = "ART-CODE".
        appointmentMappingInfo1:UniqueId = "WO-ID".

 */
        define variable lRow as DummyRow no-undo.
// this code, based on Laura's answer, repositions the top-nav-query
        lRow = cast(iApp:DataItem, Progress.data.DummyRow).
        lQueryHandle = dataset dsAppRes:top-nav-query.
        lQueryHandle:reposition-to-row(lRow:index + 1).
// still looking for a way to leave that query untouched, worst case create second query on different buffer

// this does not work UniqueId is some generated guid and not a link to the bound data
        iTTHandle:find-unique (substitute ("where &1.WO-ID = &2", iTTHandle:name, quoter(unbox(iApp:UniqueId:KeyValue)))) no-error.

        message "iApp:UniqueId:KeyValue" iApp:UniqueId:KeyValue "dataitem" lRow:Index "avail" iTTHandle:available
        view-as alert-box.

end method.

Did you try to see what was already in the buffer for the Appointments table - i.e., the buffer associated with the DataSet.  As i said, it may already have the correct record in it.  Not sure when this event is fired and whether the BindingSource:Position property will always be in sync with the row Index for this appointment.   The current record will always be in sync with the BindingSource:Position.

Yes - you should not be messing with the query that the BindingSource is using.  Though you can get the ROWID of the current record and reposition back to it when you are done.  Or use an alternate, cloned query, as you suggested.  Though in many cases it doesn't matter.  It depends on when this event fires.  

[mention:04fbfb2e92784123a464ff2aade602b1:e9ed411860ed4f2ba0265705b8793d05] thanks for your assistance

for the RADScheduler the temp-table buffer contains the last selected record (even if if was deselected).

The appointmentformatting event fires for all visible records but does not reposition.

Got following answer from Progress tech support, case 00400024 (Telerik side of the desk)

When RadScheduler is in bound mode (its DataSource property is set to a collection of records), you can extract the data item associated with each Appointment in the AppointmentFormatting event by the SchedulerAppointmentEventArgs.Appointment.DataItem property. This property will return your data record, e.g. a list record, a data row etc. After some research, I have found out that Progress.Data.DummyRow is a .NET object which is a proxy for the ABL temp-table record that holds application data. A .NET control gets a Progress.Data.DummyRow when it requests a row of data because it can only work with.NET objects. The control then asks each column descriptor of the BindingSource for the value of the corresponding field in the data row. The BindingSource passes the values for each field to the DummyRow for that record.

Since, it is more related to OpenEdge than to RadScheduler, I am looping in the Progress Support who can give you further information about the Progress.Data.DummyRow and how to extract the necessary information

So you are the person who logged the bug about issues with RadScheduler showing Appointments and Resources and grouping by Resource - yes?  Are you all set now?

[mention:04fbfb2e92784123a464ff2aade602b1:e9ed411860ed4f2ba0265705b8793d05] Yes, I'm the one that has been nagging about this ;-)

> Are you all set now?

That part works now.  This is a related issue.

The event where I need this fires a lot : 36 times for the initial display of 9 appointments,  each time an item is selected it fires for all visible items, according to the Telerik side of support this is normal.

On the ABL.Net side of the story I'm not so confident performance will be good so I need a fast, reliable way to get the temp-table record for a given appoinment.

The dummyrow:index works, and we'll use it if there is no other option but I'd feel more comfortable is there was a documented way to achieve this.

Thanks you for your interest, it's very helpful

I understand your concern.  But I don't see any other way without Telerik adding another property (rowIndex) to their SchedulerAppointmentEventArgs object.  You can ask for that, but I can't see that it will be a priority for them.

In the meantime, the Index property of the DummyRow object is not going to go away!  So I think that's pretty safe.  Under the circumstances, it does look like we need to document it.  You could log a documentation bug to get that accomplished.  THANKS.

Thanks again, reply from tech support below

Hello Carl,

I have logged documentation bug# PSC00358496 for this. Development will review and look at getting the Progress.Data.DummyRow class documented in a future release.