Brian, I can see circumstances where having those "entry" handlers you wrote as being useful and other cases where it is just extra code to write.
I think it would be useful to have them described in the OOPengine stack as an implementation suggestion and how having such handlers helps.
(and also examples of using the entry handlers or not using them)
Some samples of needs to call superClasses in a function override.
Code: Select all
void CTransact::retrieveRecordData(sqlite3_stmt *ppStmt)
{
setRowID(sqlite3_column_int64(ppStmt, 0));
*ref_idp = (long)sqlite3_column_int64(ppStmt, eTransactRef_id);
set_TextN(&trnType, (char *)sqlite3_column_text(ppStmt, eTRNTYPE));
....
setTransactionSign(); //leave debit flag as read from database
changed = false;
}
is almost the base class.
Code: Select all
void CSplit::retrieveRecordData(sqlite3_stmt *ppStmt)
{
CTransact::retrieveRecordData(ppStmt);
}
Code: Select all
void CBudget::retrieveRecordData(sqlite3_stmt *ppStmt)
{
CSplit::retrieveRecordData(ppStmt);
nextDate = (time_t)sqlite3_column_int64(ppStmt, eBudgetNextDate);
isActive = (bool)sqlite3_column_int(ppStmt, eBudgetActive);
..........
changed = false;
}
Code: Select all
void *CChargeFilterTable::getFilter(long inCardID, long inType)
{
CChargeFilter *aFilter = (CChargeFilter*)CTransFilterTable::getFilter(inCardID, inType);
if (0 == aFilter) {
aFilter = new CChargeFilter();
.....
}
return aFilter;
}
Code: Select all
- (id) initWithWindowNibName:(NSString*)windowNibName
{
if (nil == windowNibName) {
self = [super initWithWindowNibName:@"OcPopUpWindow"];
}
else
self = [super initWithWindowNibName:windowNibName];
modifyMode = false;
addMode = NO;
changedFlag = false;
sheetMode = NO; //default is a window, not a sheet
saveStyleMask = 0;
return self;
}
Code: Select all
int CWhoTable::deleteRecord(unsigned long aRowID)
{
getWhatWhoTable()->deleteAllWhatForWho(aRowID);
int rc = CBaseTable::deleteRecord(aRowID);
updateDisplayOrder(); //displayOrder needs to be sequential
return rc;
}
Just a few of the cases of calling upwards in an override.
Yes, typically I call the superclass first or last, but as you see with the last one, the call is in the middle.
Is this something that happens in every method?
No, I actually try to avoid doing it at all, but I won't kill myself to not do it either.
In any case, I believe that based on this whole investigation it has been shown that there is a means to do C++ style coding inside LiveCode with the way that behaviors have been implemented and the additional information that you (Mark, Brian, Bernd) have shared.
Special functions such as messageObject, superFunction, superCommand are not required and in IMO, counterproductive.
The beginning of this thread started with a categorical denial that C++ style coding was possible or even worthwhile.
Moving on.
So far, in order to set up the basic fields and methods for a class there has been a requirement to put buttons or some kind of visual UI element on a Card and then you can open the script editor to write the code.
But under many circumstances, the Classes that I intend to write have no UI at all and never will. They are supporting elements of the program that may be called from different places in the UI, so need to be independent of it.
Is there a means to do declare and write the code for a class and assign inheritance of a behavior without having to place a UI element on a card to start the process?