@Norman P First off I would not create 250 windows to edit tables
I'd have one windows which could edit any table and one that could lost any table - 2 windows in total
And be able to open multiple instances of these windows so if I need to edit or list more than one table at a time I can
I agree... and perhaps my 250 number was a bit of an exaggeration but even if I only have 2 resources to edit, it feels strange to have to write the same code in the ContentsChanged event handler for both of them.
I also considered the same strategy as you propose here... and I think it would work fine for the ListWindow as columns can easily be added in code... but how would you create a window that could edit any table? How would you handle an EditWindow in which the presentation of fields needs to be tailored to each object? For example, a simple UserEditWindow might only have four or five fields but a more complex object might have 20 or more fields... organized in tabs... and related lists. For basic edit windows, we might get away with using a generic EditWindow but I'm not sure how it could work for all of them.
Personally, I think that there is a time and a place for abstraction but the crafting of the user interface is not one of them.
Building each window individually seems like the best way but even the best of us resort to writing a program to write our programs. (ie: ARGen, StormORM) To me, the entire idea of Active Record goes against the very philosophy of Xojo... but that's a topic for a different thread.
Nope. Sorry. I hold Xojo to a higher standard than this. The original promise of Real Basic was programming 'for the rest of us'. It promised native, built-in controls that you could arrange in the IDE and then 'wire up' with basic code. Instead, I'm having to subclass everything and 'roll my own' with complex code (if anyone even mentions a 'declare'... I swear... ) in order to build even the most basic of business applications. Where is the DateControl? How about an EmailField that validates format... or an IntegerField or CurrencyField? These are low hanging fruit and yet there is a PasswordField?!
The DataControl was poorly implemented but genius in it's original conception. Why deprecate it? Why not modernize it? The binding of layout controls to database columns was a great idea but no one has 'flipped' through records with 'next' and 'previous' buttons since HyperCard.
It's no wonder to me why new Xojo users give up. I've tried and failed with Xojo more times over the past 20 years than I care to admit. I've bought the books, I've watched videos... I even subscribed to the magazine... and yet each time I get a little beyond Eddie's Electronics, I get tripped up with what seem to be obvious omissions in the IDE. API 2.0 sounds like a great start but it's going take a lot more than renaming some functions.