Desktop Bug Combo Boxs

I've looked at this a bit more closely and it is obvious that there is a
clearly a bug in the implementation of combo boxes.  Even static boxes 
don't work right (at least the first time you open the form; although 
they do seem work if you close the form and then reopen it.

Pre-first, there is obviously a problem with closing tags. But, I've 
manually created the .sxf with the proper closes and there is still the 
problem.

First, with respect to the font tags:

<font facename="MS Shell Dlg" pointsize="8"
weight="n" style="n" 
decoration="n" />

This to me is a sloppy shortcut.  Close the doggone tag so that we know 
that isn't the source of the error.

<font>
  <facename>"MS Shell Dlg"</facename>
  <pointsize>8</pointsize>
  <weight>n</weight>
  <style>n</style>
  <decoration>n</decoration>
</font>

Second, this is what a static combo looks like:

         <listsourcetype>static</listsourcetype>
         <listsourceentries>
           <listsourceentry>a</listsourceentry>
           <listsourceentry>b</listsourceentry>
           <listsourceentry>c</listsourceentry>
         </listsourceentries>

What is a data combo supposed to look like?  I compare this part

<!ELEMENT controlsource (fieldname, tablename) >
<!ELEMENT listsourcetype (#PCDATA) >
<!ELEMENT listsource (fieldname, tablename) >
<!ELEMENT valuesource (fieldname, tablename) >
<!ELEMENT order (fieldname, tablename) >
<!ELEMENT listsourceentries (listsourceentry*) >
<!ELEMENT listsourceentry (#PCDATA) >

with what gets put in (even discounting the lack of closing tags) and it 
is clear that something is clearly wrong.  But if I manually edit the 
.sxf, it seems actually to sort of work if I do it like this:

  <controlsource>
   <fieldname>BField</fieldname>
   <tablename>TableB</tablename>
  </controlsource>
  <listsourcetype>data</listsourcetype>
  <listsource>
   <fieldname>BField</fieldname>
   <tablename>TableB</tablename>
  </listsource>
  <valuesource>
   <fieldname>BField</fieldname>
   <tablename>TableB</tablename>
  </valuesource>
  <order></order>
Plus these are the ending tags that are missing which you have to add.
    </sdf1combo>
   </controls>
  </sdf1page>
</simpoldataform1>

But this represents  just the simpliest data filled combo. It is not 
even bound to the appropriate field in TableA like we'd want.

One might think that
<controlsource>
<fieldname>FromTableB</fieldname>
<tablename>TableA</tablename>
</controlsource>

would do the trick (plus of course with appropriate datasource tags)
But alas this doesn't work at all. I think the problem lies with how 
this stuff gets written, by the Desktop.

<!ELEMENT sdf1table (name)>
<!ATTLIST sdf1table master (y|n) "n">

<!ELEMENT sdf1link (sourcefield, sourcetable, targetfield, targettable)>
<!ELEMENT sourcefield (#PCDATA)>
<!ELEMENT sourcetable (#PCDATA)>
<!ELEMENT targetfield (#PCDATA)>
<!ELEMENT targettable (#PCDATA)>

I am not really sure how to write it manually.  Desktop writes it with 
no file as the master, I changed it to make TableA the master file. And 
Desktop choked on opening the form. (I've tried it other  ways.)

BUT, on a lark, BEFORE opening up form, I first OPENED both Tables, then 
I opened form and no not only no shut down but data actually got saved 
correctly!

JDK

Attached is a form that seems to work.  I basically had to manually edit 
the .sxf.  First to have the proper closing tags, second to have 
complete combo tags and then to make TableA a master table.  It looks 
like the desktop always writes tables master = "n".

JDK


Kromkowski wrote:
> I've looked at this a bit more closely and it is obvious that there is a
> clearly a bug in the implementation of combo boxes.  Even static boxes 
> don't work right (at least the first time you open the form; although 
> they do seem work if you close the form and then reopen it.
> 
> Pre-first, there is obviously a problem with closing tags. But, I've 
> manually created the .sxf with the proper closes and there is still the 
> problem.
> 
> First, with respect to the font tags:
> 
> <font facename="MS Shell Dlg" pointsize="8"
weight="n" style="n" 
> decoration="n" />
> 
> This to me is a sloppy shortcut.  Close the doggone tag so that we know 
> that isn't the source of the error.
> 
> <font>
>  <facename>"MS Shell Dlg"</facename>
>  <pointsize>8</pointsize>
>  <weight>n</weight>
>  <style>n</style>
>  <decoration>n</decoration>
> </font>
> 
> Second, this is what a static combo looks like:
> 
>         <listsourcetype>static</listsourcetype>
>         <listsourceentries>
>           <listsourceentry>a</listsourceentry>
>           <listsourceentry>b</listsourceentry>
>           <listsourceentry>c</listsourceentry>
>         </listsourceentries>
> 
> What is a data combo supposed to look like?  I compare this part
> 
> <!ELEMENT controlsource (fieldname, tablename) >
> <!ELEMENT listsourcetype (#PCDATA) >
> <!ELEMENT listsource (fieldname, tablename) >
> <!ELEMENT valuesource (fieldname, tablename) >
> <!ELEMENT order (fieldname, tablename) >
> <!ELEMENT listsourceentries (listsourceentry*) >
> <!ELEMENT listsourceentry (#PCDATA) >
> 
> with what gets put in (even discounting the lack of closing tags) and it 
> is clear that something is clearly wrong.  But if I manually edit the 
> .sxf, it seems actually to sort of work if I do it like this:
> 
>  <controlsource>
>   <fieldname>BField</fieldname>
>   <tablename>TableB</tablename>
>  </controlsource>
>  <listsourcetype>data</listsourcetype>
>  <listsource>
>   <fieldname>BField</fieldname>
>   <tablename>TableB</tablename>
>  </listsource>
>  <valuesource>
>   <fieldname>BField</fieldname>
>   <tablename>TableB</tablename>
>  </valuesource>
>  <order></order>
> Plus these are the ending tags that are missing which you have to add.
>    </sdf1combo>
>   </controls>
>  </sdf1page>
> </simpoldataform1>
> 
> But this represents  just the simpliest data filled combo. It is not 
> even bound to the appropriate field in TableA like we'd want.
> 
> One might think that
> <controlsource>
> <fieldname>FromTableB</fieldname>
> <tablename>TableA</tablename>
> </controlsource>
> 
> would do the trick (plus of course with appropriate datasource tags)
> But alas this doesn't work at all. I think the problem lies with how 
> this stuff gets written, by the Desktop.
> 
> <!ELEMENT sdf1table (name)>
> <!ATTLIST sdf1table master (y|n) "n">
> 
> <!ELEMENT sdf1link (sourcefield, sourcetable, targetfield,
targettable)>
> <!ELEMENT sourcefield (#PCDATA)>
> <!ELEMENT sourcetable (#PCDATA)>
> <!ELEMENT targetfield (#PCDATA)>
> <!ELEMENT targettable (#PCDATA)>
> 
> I am not really sure how to write it manually.  Desktop writes it with 
> no file as the master, I changed it to make TableA the master file. And 
> Desktop choked on opening the form. (I've tried it other  ways.)
> 
> BUT, on a lark, BEFORE opening up form, I first OPENED both Tables, then 
> I opened form and no not only no shut down but data actually got saved 
> correctly!
> 
> JDK
> 
> 

Neil Robinson wrote:
> Kromkowski wrote:
>> I've looked at this a bit more closely and it is obvious that there is
a
>> clearly a bug in the implementation of combo boxes.  Even static boxes

>> don't work right (at least the first time you open the form; although 
>> they do seem work if you close the form and then reopen it.
>>
>> Pre-first, there is obviously a problem with closing tags. But, I've 
>> manually created the .sxf with the proper closes and there is still 
>> the problem.
>>
>> First, with respect to the font tags:
>>
>> <font facename="MS Shell Dlg" pointsize="8"
weight="n" style="n" 
>> decoration="n" />
>>
>> This to me is a sloppy shortcut.  Close the doggone tag so that we 
>> know that isn't the source of the error.
>>
>> <font>
>>  <facename>"MS Shell Dlg"</facename>
>>  <pointsize>8</pointsize>
>>  <weight>n</weight>
>>  <style>n</style>
>>  <decoration>n</decoration>
>> </font>
> 
> The above is incorrect. 

I know that it is not "correct". It is a "suggestion".

>
>> <!ELEMENT controlsource (fieldname, tablename) >
>> <!ELEMENT listsourcetype (#PCDATA) >
>> <!ELEMENT listsource (fieldname, tablename) >
>> <!ELEMENT valuesource (fieldname, tablename) >
>> <!ELEMENT order (fieldname, tablename) >
>> <!ELEMENT listsourceentries (listsourceentry*) >
>> <!ELEMENT listsourceentry (#PCDATA) >
>>
>> with what gets put in (even discounting the lack of closing tags) and 
>> it is clear that something is clearly wrong.  But if I manually edit 
>> the ..sxf, it seems actually to sort of work if I do it like this:
>>
>>  <controlsource>
>>   <fieldname>BField</fieldname>
>>   <tablename>TableB</tablename>
>>  </controlsource>
>>  <listsourcetype>data</listsourcetype>
>>  <listsource>
>>   <fieldname>BField</fieldname>
>>   <tablename>TableB</tablename>
>>  </listsource>
>>  <valuesource>
>>   <fieldname>BField</fieldname>
>>   <tablename>TableB</tablename>
>>  </valuesource>
>>  <order></order>
>> Plus these are the ending tags that are missing which you have to add.
>>    </sdf1combo>
>>   </controls>
>>  </sdf1page>
>> </simpoldataform1>
>>
>> But this represents  just the simpliest data filled combo. It is not 
>> even bound to the appropriate field in TableA like we'd want.
> 
> Because you haven't bound the control itself to the database field. 

Yes, again I understand this.  I'm just trying to step by step work 
through it so that we all can see how it works.


> Please note, that the file format is not yet documented anywhere, other 
> than the DTD at the top. SIMPOL Desktop (or actually formlib.sml) does 
> in fact generate the ouput correctly normally. The version that you have 
> does contain a problem, as I have already posted.
> 
>> would do the trick (plus of course with appropriate datasource tags)
>> But alas this doesn't work at all. I think the problem lies with how 
>> this stuff gets written, by the Desktop.
>>
>> <!ELEMENT sdf1table (name)>
>> <!ATTLIST sdf1table master (y|n) "n">
>>
>> <!ELEMENT sdf1link (sourcefield, sourcetable, targetfield,
targettable)>
>> <!ELEMENT sourcefield (#PCDATA)>
>> <!ELEMENT sourcetable (#PCDATA)>
>> <!ELEMENT targetfield (#PCDATA)>
>> <!ELEMENT targettable (#PCDATA)>
> 
> The above is an embedded DTD. Unless you know how to read one, it may 
> not mean much to you, though this is fairly straightforward compared to 
> what one /can/ look like.
> 
>> I am not really sure how to write it manually.  Desktop writes it with

>> no file as the master, I changed it to make TableA the master file. 
>> And Desktop choked on opening the form. (I've tried it other  ways.)
> 
> It is strange that Desktop is not making any file a master. You are 
> reading the DTD above. This is not the form. The form begins with the 
> tag <simpoldataform1 units="pixels">. Just inside that your
data sources 
> will be listed and I am sure you will find that one of them is marked as 
> the master table. Since only one master table is allowed per form, and 
> it can't be changed, it defaults to "n" when interpreting a tag
for a 
> table that fails to include the attribute at all.
> 
>> BUT, on a lark, BEFORE opening up form, I first OPENED both Tables, 
>> then I opened form and no not only no shut down but data actually got 
>> saved correctly!
> 
> It is supposed to. It wouldn't be very useful if the form always had to 
> reopen the database tables.

Well, the bottom line is that the form I attached does "work". But to

get to it one has to manually edit the .sxf in stages.  But the downside 
is that it doesn't really work as a look up with request would for that 
you'd have to write functions that would exist outside the form per se.

This adds a level of attention.  Moreover, I haven't totally wrap head 
around how you'd not have to write a function for every field of this type.

Kromkowski wrote:
> I've looked at this a bit more closely and it is obvious that there is a
> clearly a bug in the implementation of combo boxes.  Even static boxes 
> don't work right (at least the first time you open the form; although 
> they do seem work if you close the form and then reopen it.
> 
> Pre-first, there is obviously a problem with closing tags. But, I've 
> manually created the .sxf with the proper closes and there is still the 
> problem.
> 
> First, with respect to the font tags:
> 
> <font facename="MS Shell Dlg" pointsize="8"
weight="n" style="n" 
> decoration="n" />
> 
> This to me is a sloppy shortcut.  Close the doggone tag so that we know 
> that isn't the source of the error.
> 
> <font>
>  <facename>"MS Shell Dlg"</facename>
>  <pointsize>8</pointsize>
>  <weight>n</weight>
>  <style>n</style>
>  <decoration>n</decoration>
> </font>

The above is incorrect. What you saw is not a shortcut. You have 
converted attributes to tags. There are specific reasons, having to do 
with validation using a DTD, that decides whether something should be an 
attribute or a tag. The code that reads the form will not find the 
information, and that is assuming that it doesn't fail the form on 
validation (which it should do).

> Second, this is what a static combo looks like:
> 
>         <listsourcetype>static</listsourcetype>
>         <listsourceentries>
>           <listsourceentry>a</listsourceentry>
>           <listsourceentry>b</listsourceentry>
>           <listsourceentry>c</listsourceentry>
>         </listsourceentries>
> 
> What is a data combo supposed to look like?  I compare this part

A data combo only stores the fieldname and table, it doesn't sotre the 
data, that may change.

> <!ELEMENT controlsource (fieldname, tablename) >
> <!ELEMENT listsourcetype (#PCDATA) >
> <!ELEMENT listsource (fieldname, tablename) >
> <!ELEMENT valuesource (fieldname, tablename) >
> <!ELEMENT order (fieldname, tablename) >
> <!ELEMENT listsourceentries (listsourceentry*) >
> <!ELEMENT listsourceentry (#PCDATA) >
> 
> with what gets put in (even discounting the lack of closing tags) and it 
> is clear that something is clearly wrong.  But if I manually edit the 
> ..sxf, it seems actually to sort of work if I do it like this:
> 
>  <controlsource>
>   <fieldname>BField</fieldname>
>   <tablename>TableB</tablename>
>  </controlsource>
>  <listsourcetype>data</listsourcetype>
>  <listsource>
>   <fieldname>BField</fieldname>
>   <tablename>TableB</tablename>
>  </listsource>
>  <valuesource>
>   <fieldname>BField</fieldname>
>   <tablename>TableB</tablename>
>  </valuesource>
>  <order></order>
> Plus these are the ending tags that are missing which you have to add.
>    </sdf1combo>
>   </controls>
>  </sdf1page>
> </simpoldataform1>
> 
> But this represents  just the simpliest data filled combo. It is not 
> even bound to the appropriate field in TableA like we'd want.

Because you haven't bound the control itself to the database field. 
Please note, that the file format is not yet documented anywhere, other 
than the DTD at the top. SIMPOL Desktop (or actually formlib.sml) does 
in fact generate the ouput correctly normally. The version that you have 
does contain a problem, as I have already posted.

> would do the trick (plus of course with appropriate datasource tags)
> But alas this doesn't work at all. I think the problem lies with how 
> this stuff gets written, by the Desktop.
> 
> <!ELEMENT sdf1table (name)>
> <!ATTLIST sdf1table master (y|n) "n">
> 
> <!ELEMENT sdf1link (sourcefield, sourcetable, targetfield,
targettable)>
> <!ELEMENT sourcefield (#PCDATA)>
> <!ELEMENT sourcetable (#PCDATA)>
> <!ELEMENT targetfield (#PCDATA)>
> <!ELEMENT targettable (#PCDATA)>

The above is an embedded DTD. Unless you know how to read one, it may 
not mean much to you, though this is fairly straightforward compared to 
what one /can/ look like.

> I am not really sure how to write it manually.  Desktop writes it with 
> no file as the master, I changed it to make TableA the master file. And 
> Desktop choked on opening the form. (I've tried it other  ways.)

It is strange that Desktop is not making any file a master. You are 
reading the DTD above. This is not the form. The form begins with the 
tag <simpoldataform1 units="pixels">. Just inside that your data
sources 
will be listed and I am sure you will find that one of them is marked as 
the master table. Since only one master table is allowed per form, and 
it can't be changed, it defaults to "n" when interpreting a tag for a

table that fails to include the attribute at all.

> BUT, on a lark, BEFORE opening up form, I first OPENED both Tables, then 
> I opened form and no not only no shut down but data actually got saved 
> correctly!

It is supposed to. It wouldn't be very useful if the form always had to 
reopen the database tables.

> The version I have here is working fine. It fills the list, selects the 
> correct entry for each change of record, etc. The work is all done by 
> the refresh() method of the dataform1 object.

I am confused by what you are talking about is working fine.

Creating a form in Desktop (WITHOUT manually fixing .sxf) and having it 
work correctly as a form?  I don't think this is possible.

Or creating a form via SIMPOL language and having it work correctly?

Or something else.

I posted a very simple sort of working form.  Perhaps you can post what 
you have working, so that we can all compare.

There is also the mechanics of what a simpol program would actually look 
like.

I'll post later.  I have jury trial starting on monday.