Problem/Bugs in Desktop 4f

I open a table.  Table view NOT form view.  Have not got that far 
without problems.

I enter a date  "1/1/1995" into a date field.  When I click to another

field. Or if I then TAB. Or if I hit Enter. (What, btw, is the right way 
to move from field to field?)
SHUT DOWN.

I've tried entering the date as

January 1, 1995  - Shut down
Jan 1 1995 - Shut down
1 Jan 1995 - Shut down
28/May/2001 which is the form of date displayed in adrb date fields - 
Shut down
28/5/2001 - Shut down.

Ironically (i guess), if I enter 728283 in the filed, I get a dialog
that says "Error Retrieving the field value from the text you
entered."

BUT, it goes on to APPEAR to save 728283 in the field!  Alas, when you 
reopen the TABLE that field is blank.

The error appears on other Tables.

OK.  I finally have stumbled upon the fact that this behavior does not 
occur in "adrb".

So, I use Desktop to create a new table called Test.
It has one field a date field.

Same shut down issues.  I've attached it.

But now I go back to "adrb" Table just to verify.

And now the date fields are displayed in this format
"20010528". Even though, when I first opened up that file to test they

were displayed as "28 May 2001" format.

BUT then out of desperation, I choose modify file and look at adrb.
I see after scrolling the Display Format column. It says "yyyy0m0d".

I then open up my Test table in the modify grid and see that the Display 
Format is listed as

"m/d/yyyy"  which apparently is the default, but as one needs to
scroll 
to look at those columns, I didn't.

So if I change the Display Format from "m/d/yyyy" to
"yyyy/0m/0d", I
can add a data to a date field.

Obviously, there are many mixed feelings - none good - that this first 
experience of "4f" has generated.

I want to be clear that I don't see Desktop so much as an application 
but a RAD tool adjunct to the IDE to quickly create tables and forms.

JDK

PS. I took 30 seconds to create a simple form. The total freeze that 
occurred when dealing with a date field, was sort of the icing on the cake.

Let me approach the problems I described before a different way.

When looking at the Table "information" under Modify Table in the 
Desktop (is there a better way to refer to that like "Table Info 
Grid"?), i.e the Simpol's equivalent of SBL's CALL ModifyFile():

What does the column "display format" actually represent?

As far as I can tell it is not a property inherent to the SBME object.
Actually, let me be more precise, as far as I can tell it is not a 
property inherent to a "sbme1field" object.
Is that understanding correct?

If that understanding is correct, is it some type of "application" 
property that you have created as part of the Desktop smp?

If that is the situation,

1) what is the code that creates it so that we can try to debug it?
2) what is the downside of having it actually as a property of the 
sbme1field object.

The documentation says:

"There are a number of differences between the SBME database design and 
that of the older Superbase format. One thing that immediately is 
noticeable is the lack of a column width or display format.  Another big 
difference is that there are no field characteristics like "read
only", 
"required", "non-stored", nor any validation, default or
calculation 
formulae [sic? "formulas"]. The reasons for this are numerous. Ovedr 
[sic]the years most of the more advanced Superbase programmers have 
found that the use of these features tends to cause more trouble than 
they are worth."

"The only ones to profit from the use of such features tend to be very 
simple databases with little or no significant program code. The more 
complex an application becomes the more restrictive the use of these 
features becomes. As such, the right place to put these types of 
features is in the code that is responsible for saving records in a 
given table."

If you guys (as "more advanced Superbased programmers") can't get seem

to get this right in the Desktop, then maybe the premise that has kept 
these properties:

column width
display format
read only
required
non-stored
calculations
validations (of which, I consider default to be a sort of version)

out of the field objects (of whatever flavor: sbme1, ppcs1, or db1) is 
mistaken.

I just don't get how these features would create more trouble than they 
are worth for the "more advanced Superbase programmer".

What it means for me is that I have to figure out how to put these 
features in the code that is responsible for saving a given table. Of 
course, I think that I am competent enough to eventually figure this 
out.  But why should each of the 17 people using Simpol have to reinvent 
this wheel in a product that is billed as a RAD tool.

JDK

> The Table Designer.

Got it.

>> What does the column "display format" actually represent?
>> As far as I can tell it is not a property inherent to the SBME object.
>> Actually, let me be more precise, as far as I can tell it is not a 
>> property inherent to a "sbme1field" object.
>> Is that understanding correct?
> 
> It is not part of the SBME object. It is clear that this information is 
> useful to store in a central place, but the pure storage engine that we 
> have in sbme1 does not cater to these needs. Therefore, a methodology 
> was created that allows for a relatively easily extensible table 
> information capability. This information is stored inside the *.sbm file 
> in a set of three system tables: systables, sysfields, and sysfieldsext. 
> There is a set of functions provided in db1util.sml (see source code 
> project for the particulars) that allow you to add tables to an *.sbm 
> file and to maintain the information in the system tables. This same set 
> of functions is used by the File Designer.

I don't see in the documentation about systables, sysfields and 
sysfieldsext.

I knew you were using them as part of Desktop, but it was not clear to 
me whether they were just being created for purpose of Desktop or from 
some broader use.


> It is not really an application property. The file format string that is 
> stored in the table definition is read out when the table is opened via 
> sbme1 if that is done within SIMPOL Desktop. If none is defined, then 
> the default format is retrieved using the getdefaultformat() function. 
> This may yet be overridden by retrieving the system locale information 
> to find out things like the default date format, decimal and thousands 
> separator, etc.

OK, but you can't set the system local information in the Desktop.  Most 
of menu items under Options is non-functional.  Notably system, 
display,messages, and locale.

How does one set the default date format, decimal etc.


> To allow calculation 
> formulae ( see this link for the correct formulation of plurals of loan 
> words of Greek or Latin origin: 
> http://www2.gsu.edu/~wwwesl/egw/pluralsn.htm), 

Well, maybe you've been in the UK too long.  I think that outside of 
mathematical journals the preferred plural is form of formula is 
"formulas" although formulae is not incorrect.

> 
>> The documentation says:
>>
>> "There are a number of differences between the SBME database
design 
>> and that of the older Superbase format. One thing that immediately is 
>> noticeable is the lack of a column width or display format.  Another 
>> big difference is that there are no field characteristics like
"read 
>> only", "required", "non-stored", nor any
validation, default or 
>> calculation formulae [sic? "formulas"]. The reasons for this
are 
>> numerous. Ovedr [sic]the years most of the more advanced Superbase 
>> programmers have found that the use of these features tends to cause 
>> more trouble than they are worth."
>>
>> "The only ones to profit from the use of such features tend to be
very 
>> simple databases with little or no significant program code. The more 
>> complex an application becomes the more restrictive the use of these 
>> features becomes. As such, the right place to put these types of 
>> features is in the code that is responsible for saving records in a 
>> given table."
>>
>> If you guys (as "more advanced Superbased programmers") can't
get seem 
>> to get this right in the Desktop, then maybe the premise that has kept

>> these properties:
>>
>> column width
>> display format
>> read only
>> required
>> non-stored
>> calculations
>> validations (of which, I consider default to be a sort of version)
>>
>> out of the field objects (of whatever flavor: sbme1, ppcs1, or db1) is

>> mistaken.
> 
> No, not mistaken. As I said, I still want them, but that doesn't change 
> the fact that it needs to be possible to use a pure storage API from the 
> language as well, and the one you want would be built on top of the other.
> 
> Ever had a situation where you needed to update a database but didn't 
> want one of the calculations to fire? 

Yeah. But in those very rare circumstances, I remove the calculation, do 
the update and then put it back.

I use calculations sparingly and only for those things that I know must 
be and will be calculated the same way every time.

> The project db1util in projects\libs contains the vast majority of the 
> functions that are being called to read a value from a control and 
> assign it to a field, or to read a value from a field and format it for 
> display. If you want to examine those functions in greater detail, you 
> certainly can. I rewrote much of the underlying support in SIMPOL 
> Desktop based on the error reports you made from the last release, and 
> if I missed something along the way, I will be happy to sort it out. 

Well, back to the basic bug that involves dates:

Unless one is careful to assign the proper DisplayFormat in the Table 
Designer, then you are going to get crashes.

But it is not at all clear to me what the proper acceptable 
DisplayFormat is supposed to be and when.  Nor does it appear that the 
proper acceptably assigned DisplayFormat is even the default displayformat!

Adding the First Record


Once you figure out the trick I suppose this isn't a problem, but ...

Create a Table.  (File>New>Table)  Close the Table Designer after adding 
   fields.

Now you are in record view. Except, of course, there are no records.

IF you go to Data>Add  you'll be OK.  But suppose instead you just go 
straight to the record.  Put your cursor into first field and type away.

Then you decide to save that first record.

You now go to Data.   Hmm - save is disabled.  Ok I choose Add.

And you get a dialog that asks whether you want to save.  You choose yes.

But are you really saving the record.  NO.

Because then having seen "data>add" you choose it again, thinking
to add 
the second record.  And what do you get? The same do you want to save 
dialog.

In fact, if you choose any of the record movement buttons you get the 
same do you want to save dialog.  And you can push yes all day. But you 
aren't really saving anything.  (Well, not exactly nothing, as we shall 
see, because the recid_ro_internal is in fact being incremented!)

So then you finally catch on that something is screwed up decide to 
close the table.  Rats, same save dialog and it doesn't close down if 
you choose yes.  If you choose "No" it closes ENTIRE desktop not just

the table in question.

So then you reopen the Desktop and go to the table in question.  No 
record is there.  But this time you catch on and choose Data>Add, and 
the first thing you notice is that recid_ro_internal is created and it 
ain't 0000001 it is how every many time you tried to save it before.


JDK

Kromkowski wrote:
> Let me approach the problems I described before a different way.
> 
> When looking at the Table "information" under Modify Table in the

> Desktop (is there a better way to refer to that like "Table Info 
> Grid"?), i.e the Simpol's equivalent of SBL's CALL ModifyFile():

The Table Designer.

> What does the column "display format" actually represent?
> 
> As far as I can tell it is not a property inherent to the SBME object.
> Actually, let me be more precise, as far as I can tell it is not a 
> property inherent to a "sbme1field" object.
> Is that understanding correct?

It is not part of the SBME object. It is clear that this information is 
useful to store in a central place, but the pure storage engine that we 
have in sbme1 does not cater to these needs. Therefore, a methodology 
was created that allows for a relatively easily extensible table 
information capability. This information is stored inside the *.sbm file 
in a set of three system tables: systables, sysfields, and sysfieldsext. 
There is a set of functions provided in db1util.sml (see source code 
project for the particulars) that allow you to add tables to an *.sbm 
file and to maintain the information in the system tables. This same set 
of functions is used by the File Designer.

> If that understanding is correct, is it some type of
"application" 
> property that you have created as part of the Desktop smp?
> 
> If that is the situation,
> 
> 1) what is the code that creates it so that we can try to debug it?

It is not really an application property. The file format string that is 
stored in the table definition is read out when the table is opened via 
sbme1 if that is done within SIMPOL Desktop. If none is defined, then 
the default format is retrieved using the getdefaultformat() function. 
This may yet be overridden by retrieving the system locale information 
to find out things like the default date format, decimal and thousands 
separator, etc.

> 2) what is the downside of having it actually as a property of the 
> sbme1field object.

The current design calls for a low-level pure storage database as the 
first deliverable. Later on, a higher-level API will be provided that 
includes things like calculations, validations, constants, and other 
limitations, such as range checking.

The downside of this is that it will be considerably slower and require 
more resources than the pure storage API. SIMPOL is a compiled, not an 
interpreted language, and unlike Superbase, it is not a monolithic 
package. Even in the Superbase runtime the entire Superbase product is 
present, it is just that the access to various development areas has 
been disabled. In SIMPOL, only the pieces required by the compiled 
program are actually required to be present. To allow calculation 
formulae ( see this link for the correct formulation of plurals of loan 
words of Greek or Latin origin: 
http://www2.gsu.edu/~wwwesl/egw/pluralsn.htm), would potentially require 
the database component to demand the loading of other code, plus we 
would need to establish a way of storing compiled executable code in a 
place in the table definition. We decided this would be an acceptable 
second stage API, but not a first stage one.

> The documentation says:
> 
> "There are a number of differences between the SBME database design
and 
> that of the older Superbase format. One thing that immediately is 
> noticeable is the lack of a column width or display format.  Another big 
> difference is that there are no field characteristics like "read
only", 
> "required", "non-stored", nor any validation, default
or calculation 
> formulae [sic? "formulas"]. The reasons for this are numerous.
Ovedr 
> [sic]the years most of the more advanced Superbase programmers have 
> found that the use of these features tends to cause more trouble than 
> they are worth."
> 
> "The only ones to profit from the use of such features tend to be very

> simple databases with little or no significant program code. The more 
> complex an application becomes the more restrictive the use of these 
> features becomes. As such, the right place to put these types of 
> features is in the code that is responsible for saving records in a 
> given table."
> 
> If you guys (as "more advanced Superbased programmers") can't get
seem 
> to get this right in the Desktop, then maybe the premise that has kept 
> these properties:
> 
> column width
> display format
> read only
> required
> non-stored
> calculations
> validations (of which, I consider default to be a sort of version)
> 
> out of the field objects (of whatever flavor: sbme1, ppcs1, or db1) is 
> mistaken.

No, not mistaken. As I said, I still want them, but that doesn't change 
the fact that it needs to be possible to use a pure storage API from the 
language as well, and the one you want would be built on top of the other.

> I just don't get how these features would create more trouble than they 
> are worth for the "more advanced Superbase programmer".

Ever had a situation where you needed to update a database but didn't 
want one of the calculations to fire? If they are in the database table 
definition, it becomes much more complicated. This is a simple example 
off the top of my head, I am sure others can chime in with their own.

As for column width and display format, there are numerous other things 
that should be available but are not. When we choose to add this stuff 
back, it will be more complete than what you had in the past. In 
Superbase, the display format is used to decide the maximum value that 
can be entered into a numeric field, but in fact, it doesn't prevent 
invalid values being entered, if for example you don't want negative 
values added.

> What it means for me is that I have to figure out how to put these 
> features in the code that is responsible for saving a given table. Of 
> course, I think that I am competent enough to eventually figure this 
> out.  But why should each of the 17 people using Simpol have to reinvent 
> this wheel in a product that is billed as a RAD tool.

The project db1util in projects\libs contains the vast majority of the 
functions that are being called to read a value from a control and 
assign it to a field, or to read a value from a field and format it for 
display. If you want to examine those functions in greater detail, you 
certainly can. I rewrote much of the underlying support in SIMPOL 
Desktop based on the error reports you made from the last release, and 
if I missed something along the way, I will be happy to sort it out. 
Thanks for those detailed reports from last time. If you check the 
release notes, you may recognize quite a few of your bug reports.