Automatic Data Entry

[Peter De Berdt]

On 27 Oct 2004, at 23:59, Chuck Pelto wrote:

>
> On Oct 27, 2004, at 5:20 AM, Peter De Berdt wrote:
>
>> This is something you have to code in REALbasic (or whatever 
>> environment you're programming in), not from Valentina (you could use 
>> a calculation/method field, but this can't be changed). If your 
>> application is object-oriented, this should be very easy (because 
>> your object will automatically generate the field). Once you get the 
>> grasp of object-oriented programming and your framework classes are 
>> well written, you'll soon discover all the repeating and tedious work 
>> you need to do in Filemaker simply isn't necessary. If you try to 
>> maintaining the same workflow of Filemaker, i.e. throwing in another 
>> field whenever you like, coding in the controls themselves instead of 
>> thinking out a decent structure, your application will soon become 
>> unmaintainable.
>
> Are you suggesting that each record in a database system designed with 
> Valentina is an object in and of itself?
>
No, you need to have a class to which you pass your record and that 
class then automatically adds your merged constant-field to the insert.

Let me give you an example. Using my framework, I can just drop some 
control subclasses on a window, give them a name, type, maxlength, ... 
If the SchemaVersion of the database doesn't match a constant 
"CurrentVersion" in my REALbasic project, I instantiate all windows and 
loop the controls. If they are of a certain ClassInterface, my 
REALbasic app checks if the field exists in the database and if the 
type is correct, if not, it updates the database structure. My Window 
subclass automatically handles editing, saving, ... records. I could 
easily add a new class "ConstantDatabaseField" using the same 
ClassInterface "DatabaseObject", which would then also be included in 
the chain of fields to be checked.

I still have my early versions of the framework lying around, I'm 
prepared to send them over to you directly if you want to have a look, 
mail me offlist. It won't be bug free, and is not optimized, but you'll 
probably find some parts of it very useful. A grasp of the features: 
instant multilanguage (able to change application language at runtime, 
not using REALbasic's constants way), automatic adding of new fields to 
the db, automatic saving of records, handling of changes and asking the 
user wether or not he wants to save a record, discard it or cancel the 
action (i.e. the commit feature added in Filemaker 7) and a lot more, I 
don't remember. I think I'm using Einhugur plug-ins (DataGrid mainly) 
in my testing, so you may need to download those.

>> Once you get the grasp of object-oriented programming and your 
>> framework classes are well written, you'll soon discover all the 
>> repeating and tedious work you need to do in Filemaker simply isn't 
>> necessary. If you try to maintaining the same workflow of Filemaker, 
>> i.e. throwing in another field whenever you like, coding in the 
>> controls themselves instead of thinking out a decent structure, your 
>> application will soon become unmaintainable.
>
> One of the great aspects of FMP is that you have the flexibility to 
> modify the data file/table, database structure at will at any time.
>
> As the old adage goes, "NOTHING endures like 'change'." We are 
> constantly changing things. Have a structure that is cast in concrete 
> makes it very difficult to cope with such a concept as 'change'. But 
> change it must. Especially if it is going to survive. Most especially 
> in a competitive environment.
>
> And maybe that's what V Studio is supposed to help with; changing a 
> Valentina database structure without breaking the application. I 
> certainly hope so.
>
You can alter your database structure using SQL too, but it's not the 
same as just opening up Field Definitions and changing a field's name 
or type. But generally speaking, changing a field's type should not be 
necessary (in Filemaker you have to change it sometimes if you want to 
get things to work, in Valentina a field that holds an number, will 
always be a number-type field, it shouldn't be text).

Best regards

Peter De Berdt