Steve
I too was hoping for a few refinements being added to MVP but 90 views and no responses seems to indicate that no one else is on here actually using it.
Except me that is as I am currently developing an app based solely on this methodology.
I should clarify this by saying that this is Property Letting app being written for a friend and as such I am under no real pressures but none the less it will still need to provide all the necessarry functionality when finished.
There are a few points worth noting if you are going to have a go with this.
It is only available in WD so no option to share functionality with WB or WM.
The examples whilst using the MVP functions was not actually made using the RAD.
Not an issue in itself as you can learn a lot by stepping through the code but you will need to be wearing a 'Sherlock Holmes Deerstalker' as information on a most of MVP is pretty hard to come by.
MVP RAD is, like most RAD, pretty simplistic in that it assumes you will be making an app that only requires a number of tables that call an add/update window.
If you use ribbons or tabs you are on your own.
Each RAD operation can/will only produce one form or table for the selected data file.
So 50 data files would require 100 RAD operations to produce the classes.
The corresponding form/table is always generated wether you want/need them or not.
The code produced in the 'Request for refreshing' section of the window is useless as it will always select the row you were on prior to editing regardles of whether the sort order of the array has changed.
I did send PCS a project highlighting this with a proposed solution - had an email thanking me but as yet no change.
The provided error handling class is pretty much a skeleton - no had time to investigate this one yet.
So why am I using it I hear you ask......
Well actually now I am used to it and understand most of what is going on I do like it.
It is based on SQL (roll your own) queries, arrays and bound (to the array of the <presenter>)tables which is right up my street.
I use 4 codebricks following creation of a form/table pair so within a couple of minutes I can get the code cahnges I need.
Outside of that all the provided class methods work without any interference from me.
The <presenter> variable enables me to see (in debug) not only the values of the record but also, when in table mode, the contents of the array.
When creating a new record it is a new (empty except for DB default values) presenter that is sent to the form therefore any information required can be added at this stage - no need to send rafts of parameters to, or use HReadSeeks in, the window to be opened.
When updating it is the currently selected record that is sent so all that is needed on the form is 'SourceToScreen()'
The only other thing you will need to consider is how you put your app together.
I am using ribbons that frequently have tabs on the individual panes which poses a couple of issues.
Every table or form on a window needs its own <presenter> declared.
These are always declared as dynamic and therefore would need allocating (with or without data) in the global declarations of the window to avoid runtime errors.
The 'Request for refreshing' section of the window is only designed to operate with a single table control so this would need adaptation to be able to work.
My solution to these issues is to use internal windows which enables me to keep all MVP functionality where I need it.
OK, enough - you may be losing the will to live by now.
If you decide to have a go then please PM me if you have any specific questions - I may not know thw answer.
I do have a document somewhere I put together showing the basics of how I got this to work - send me your email and I will send a copy if you so require.