TDBComboBox (and then again a browse) error (example included)

[Mahanimann]

Hi,
The included sample project produce a couple of errors which I think should
be handled. The included datasource is a SQLite database, but the same
behaviour occour using TMySQLDataSource.
(My path to SQLite.LIB is C:XailerLib)
**************
TDBComboBox:
**************
When utilizing the :nDataType=="dtBOUND" feature .AND. :nStyle == csDROPDOWN
the combobox buffer is updated with the field value (or the :aItemsBound
value, I don't know) rather than the value from :aItems.
When utilizing the :nDataType=="dtBOUND" feature .AND. :nStyle ==
csDROPDOWNLIST the combobox buffer is not updated at all.
***********
TDBBrowse:
***********
*** This error only occour when the TDBComboBox is enabled .AND. when the
:nDataType=="dtBOUND" .AND. :nStyle == csDROPDOWN:
SKIP'ing to EOF() with the TDBNavigator works correct, but set focus to the
browse and use K_DOWN until you reach EOF(), then this error occour:
(b)TDBCOMBOBOX:SETTEXT(395)
Error BASE/1070 Argument error: ==
Arguments: ( [ 1] = Type: C Val: 1 - One [ 2] = Type: N Val: 0)
This happens because the TDBBrowse somehow goes into EDIT-mode (disable the
TDBComboBox or change oComboBox:nStyle to csDROPDOWNLIST and watch the
TDBNavigator) even if all the oBrowse:lAllowXXX is set to FALSE.
*** If you change the oComboBox:nStyle to csDROPDOWNLIST, the EOF() error
does not occour. Instead, the browse goes into EDIT-mode and updates the
combobox with the first value from oComboBox:aItems. ALSO (when
nStyle==csDROPDOWNLIST): When doing ordinary SKIP'ing (either in the browse
or via TDBNavigator) the combobox is not updated with any value.
*********
TDBLabel:
*********
Alignment issues: The alignment of the text is .NOT. taLEFT, it is between
taLEFT and taCENTER. The taCENTER is between taCENTER and taRIGHT. taRIGHT
is correct.
Regards,
Paal


Attached files ComboTest.zip (3.2 KB)Â

[ignacio]

Paal,
> When utilizing the :nDataType=="dtBOUND" feature .AND. :nStyle ==
> csDROPDOWN
> the combobox buffer is updated with the field value (or the :aItemsBound
> value, I don't know) rather than the value from :aItems.
The field value. You MUST 'of course' use csDROPDOWNLIST in order to use
aItemsBound.
> When utilizing the :nDataType=="dtBOUND" feature .AND. :nStyle ==
> csDROPDOWNLIST the combobox buffer is not updated at all.
The same as above.
> SKIP'ing to EOF() with the TDBNavigator works correct, but set focus to
> the
> browse and use K_DOWN until you reach EOF(), then this error occour:
>
> (b)TDBCOMBOBOX:SETTEXT(395)
> Error BASE/1070 Argument error: ==
> Arguments: ( [ 1] = Type: C Val: 1 - One [ 2] = Type: N Val: 0)
Without a working sample I can not assure but I believe this bug is already
corrected. BTW, if you send us a sample I will take a closer look.
> *** If you change the oComboBox:nStyle to csDROPDOWNLIST, the EOF() error
> does not occour. Instead, the browse goes into EDIT-mode and updates the
> combobox with the first value from oComboBox:aItems. ALSO (when
> nStyle==csDROPDOWNLIST): When doing ordinary SKIP'ing (either in the
> browse
> or via TDBNavigator) the combobox is not updated with any value.
Sorry, impossible to follow. Please send us a sample.
*********
> TDBLabel:
> *********
> Alignment issues: The alignment of the text is .NOT. taLEFT, it is
> between
> taLEFT and taCENTER. The taCENTER is between taCENTER and taRIGHT.
> taRIGHT
> is correct.
>
Please a sample. Thanks
Regards,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com

[NoName]

Paal,
> When utilizing the :nDataType=="dtBOUND" feature .AND. :nStyle ==
> csDROPDOWN
> the combobox buffer is updated with the field value (or the :aItemsBound
> value, I don't know) rather than the value from :aItems.
The field value. You MUST 'of course' use csDROPDOWNLIST in order to use
aItemsBound.
> When utilizing the :nDataType=="dtBOUND" feature .AND. :nStyle ==
> csDROPDOWNLIST the combobox buffer is not updated at all.
The same as above.
> SKIP'ing to EOF() with the TDBNavigator works correct, but set focus to
> the
> browse and use K_DOWN until you reach EOF(), then this error occour:
>
> (b)TDBCOMBOBOX:SETTEXT(395)
> Error BASE/1070 Argument error: ==
> Arguments: ( [ 1] = Type: C Val: 1 - One [ 2] = Type: N Val: 0)
Without a working sample I can not assure but I believe this bug is already
corrected. BTW, if you send us a sample I will take a closer look.
> *** If you change the oComboBox:nStyle to csDROPDOWNLIST, the EOF() error
> does not occour. Instead, the browse goes into EDIT-mode and updates the
> combobox with the first value from oComboBox:aItems. ALSO (when
> nStyle==csDROPDOWNLIST): When doing ordinary SKIP'ing (either in the
> browse
> or via TDBNavigator) the combobox is not updated with any value.
Sorry, impossible to follow. Please send us a sample.
*********
> TDBLabel:
> *********
> Alignment issues: The alignment of the text is .NOT. taLEFT, it is
> between
> taLEFT and taCENTER. The taCENTER is between taCENTER and taRIGHT.
> taRIGHT
> is correct.
>
Please a sample. Thanks
Regards,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com

[Mahanimann]

> Sorry, impossible to follow. Please send us a sample.
The sample is included. See the file attatchment "ComboTest.ZIP" in the
first post.
Regards,
Paal

[Mahanimann]

> Sorry, impossible to follow. Please send us a sample.
The sample is included. See the file attatchment "ComboTest.ZIP" in the
first post.
Regards,
Paal

[ignacio]

Paal,
You should CANCEL edit mode when you move the row number on the browse. In
my opinion is better to complete disable the Browse when in Edit mode. That
is what we do on sample DbfData1
Is not correct to have two EDIT datacontrols pointing to same datafield (
oDbMaskEdit1 & oCombo) for obvious reasons.
There was a bug on SQLiteRecords.prg an the field CharNumber was treated as
if it was numeric. That is why dtBOUND did not work correctly. Now is fixed
Regards,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Mahanimann" <paaldalen@gmail.com> escribió en el mensaje
news:[email=474ac542@ozsrv2.ozlan.local...]474ac542@ozsrv2.ozlan.local...[/email]
>> Sorry, impossible to follow. Please send us a sample.
>
> The sample is included. See the file attatchment "ComboTest.ZIP" in the
> first post.
>
> Regards,
> Paal
>

[NoName]

Paal,
You should CANCEL edit mode when you move the row number on the browse. In
my opinion is better to complete disable the Browse when in Edit mode. That
is what we do on sample DbfData1
Is not correct to have two EDIT datacontrols pointing to same datafield (
oDbMaskEdit1 & oCombo) for obvious reasons.
There was a bug on SQLiteRecords.prg an the field CharNumber was treated as
if it was numeric. That is why dtBOUND did not work correctly. Now is fixed
Regards,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Mahanimann" <paaldalen@gmail.com> escribió en el mensaje
news:[email=474ac542@ozsrv2.ozlan.local...]474ac542@ozsrv2.ozlan.local...[/email]
>> Sorry, impossible to follow. Please send us a sample.
>
> The sample is included. See the file attatchment "ComboTest.ZIP" in the
> first post.
>
> Regards,
> Paal
>

[Mahanimann]

> You should CANCEL edit mode when you move the row number on the browse. In
> my opinion is better to complete disable the Browse when in Edit mode.
> That is what we do on sample DbfData1
I totally agree and do that in my app, but that was not the point. The
point is that when skipping down the browse (in VIEW-mode) using K_DOWN, the
browse dataset enters EDIT-mode automatically when reaching EOF(). Try it
(in VIEW-mode, push K_DOWN when standing on the last row in the browse), and
watch what happens to the GET's and the TDBNavigator.
> Is not correct to have two EDIT datacontrols pointing to same datafield
> ( oDbMaskEdit1 & oCombo) for obvious reasons.
Yes, I don't do that, except for in this test to show the real value of the
field CharNumber.
> There was a bug on SQLiteRecords.prg an the field CharNumber was treated
> as if it was numeric. That is why dtBOUND did not work correctly. Now is
> fixed
That's good. But then the same error should be found in
MySQLRecords.prg(?).
Regards,
Paal

[Mahanimann]

> You should CANCEL edit mode when you move the row number on the browse. In
> my opinion is better to complete disable the Browse when in Edit mode.
> That is what we do on sample DbfData1
I totally agree and do that in my app, but that was not the point. The
point is that when skipping down the browse (in VIEW-mode) using K_DOWN, the
browse dataset enters EDIT-mode automatically when reaching EOF(). Try it
(in VIEW-mode, push K_DOWN when standing on the last row in the browse), and
watch what happens to the GET's and the TDBNavigator.
> Is not correct to have two EDIT datacontrols pointing to same datafield
> ( oDbMaskEdit1 & oCombo) for obvious reasons.
Yes, I don't do that, except for in this test to show the real value of the
field CharNumber.
> There was a bug on SQLiteRecords.prg an the field CharNumber was treated
> as if it was numeric. That is why dtBOUND did not work correctly. Now is
> fixed
That's good. But then the same error should be found in
MySQLRecords.prg(?).
Regards,
Paal

[Mahanimann]

>> When utilizing the :nDataType=="dtBOUND" feature .AND. :nStyle ==
>> csDROPDOWN
>> the combobox buffer is updated with the field value (or the :aItemsBound
>> value, I don't know) rather than the value from :aItems.
> The field value. You MUST 'of course' use csDROPDOWNLIST in order to use
> aItemsBound.
Ok, then I put this on my wishlist:
1. Update the doc's on TComboBox:nStyle with a small note about this.
2. Make the dtBOUND feature available on editable TComboBox'es (:nStyle ==
csDROPDOWN).
I understand that number 2 is not your top priority, but someday you might
find time for it .
Thanks,
Paal

[Mahanimann]

>> When utilizing the :nDataType=="dtBOUND" feature .AND. :nStyle ==
>> csDROPDOWN
>> the combobox buffer is updated with the field value (or the :aItemsBound
>> value, I don't know) rather than the value from :aItems.
> The field value. You MUST 'of course' use csDROPDOWNLIST in order to use
> aItemsBound.
Ok, then I put this on my wishlist:
1. Update the doc's on TComboBox:nStyle with a small note about this.
2. Make the dtBOUND feature available on editable TComboBox'es (:nStyle ==
csDROPDOWN).
I understand that number 2 is not your top priority, but someday you might
find time for it .
Thanks,
Paal

[ignacio]

Paal,
> point is that when skipping down the browse (in VIEW-mode) using K_DOWN,
> the browse dataset enters EDIT-mode automatically when reaching EOF().
> Try it (in VIEW-mode, push K_DOWN when standing on the last row in the
> browse), and watch what happens to the GET's and the TDBNavigator.
Tried. Nothings happens at all. Sorry.
> That's good. But then the same error should be found in
> MySQLRecords.prg(?).
No. But as I told you a bug fix was already done in this class due a error
reported by Bingen.
Regards,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Mahanimann" <paaldalen@gmail.com> escribió en el mensaje
news:[email=474b4009@ozsrv2.ozlan.local...]474b4009@ozsrv2.ozlan.local...[/email]
>> You should CANCEL edit mode when you move the row number on the browse.
>> In my opinion is better to complete disable the Browse when in Edit mode.
>> That is what we do on sample DbfData1
>
> I totally agree and do that in my app, but that was not the point. The
> point is that when skipping down the browse (in VIEW-mode) using K_DOWN,
> the browse dataset enters EDIT-mode automatically when reaching EOF().
> Try it (in VIEW-mode, push K_DOWN when standing on the last row in the
> browse), and watch what happens to the GET's and the TDBNavigator.
>
>> Is not correct to have two EDIT datacontrols pointing to same datafield
>> ( oDbMaskEdit1 & oCombo) for obvious reasons.
>
> Yes, I don't do that, except for in this test to show the real value of
> the field CharNumber.
>
>> There was a bug on SQLiteRecords.prg an the field CharNumber was treated
>> as if it was numeric. That is why dtBOUND did not work correctly. Now is
>> fixed
>
> That's good. But then the same error should be found in
> MySQLRecords.prg(?).
>
> Regards,
> Paal
>

[NoName]

Paal,
> point is that when skipping down the browse (in VIEW-mode) using K_DOWN,
> the browse dataset enters EDIT-mode automatically when reaching EOF().
> Try it (in VIEW-mode, push K_DOWN when standing on the last row in the
> browse), and watch what happens to the GET's and the TDBNavigator.
Tried. Nothings happens at all. Sorry.
> That's good. But then the same error should be found in
> MySQLRecords.prg(?).
No. But as I told you a bug fix was already done in this class due a error
reported by Bingen.
Regards,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Mahanimann" <paaldalen@gmail.com> escribió en el mensaje
news:[email=474b4009@ozsrv2.ozlan.local...]474b4009@ozsrv2.ozlan.local...[/email]
>> You should CANCEL edit mode when you move the row number on the browse.
>> In my opinion is better to complete disable the Browse when in Edit mode.
>> That is what we do on sample DbfData1
>
> I totally agree and do that in my app, but that was not the point. The
> point is that when skipping down the browse (in VIEW-mode) using K_DOWN,
> the browse dataset enters EDIT-mode automatically when reaching EOF().
> Try it (in VIEW-mode, push K_DOWN when standing on the last row in the
> browse), and watch what happens to the GET's and the TDBNavigator.
>
>> Is not correct to have two EDIT datacontrols pointing to same datafield
>> ( oDbMaskEdit1 & oCombo) for obvious reasons.
>
> Yes, I don't do that, except for in this test to show the real value of
> the field CharNumber.
>
>> There was a bug on SQLiteRecords.prg an the field CharNumber was treated
>> as if it was numeric. That is why dtBOUND did not work correctly. Now is
>> fixed
>
> That's good. But then the same error should be found in
> MySQLRecords.prg(?).
>
> Regards,
> Paal
>

[ignacio]

Paal,
1) Already done (did it yesterday)
2) Is not a question of priority I am afraid, is a question of logical
integrity. For example asume the following:
aItems:= {"One", "Two", "Three"}; aItemsBound := { 1, 2, 3 }
If the user inputs "Four" or whatever, then nIndex should be zero and
ItemsBound is useless
Regards,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Mahanimann" <paaldalen@gmail.com> escribió en el mensaje
news:[email=474b4754@ozsrv2.ozlan.local...]474b4754@ozsrv2.ozlan.local...[/email]
>>> When utilizing the :nDataType=="dtBOUND" feature .AND. :nStyle ==
>>> csDROPDOWN
>>> the combobox buffer is updated with the field value (or the :aItemsBound
>>> value, I don't know) rather than the value from :aItems.
>
>> The field value. You MUST 'of course' use csDROPDOWNLIST in order to use
>> aItemsBound.
>
> Ok, then I put this on my wishlist:
>
> 1. Update the doc's on TComboBox:nStyle with a small note about this.
> 2. Make the dtBOUND feature available on editable TComboBox'es (:nStyle ==
> csDROPDOWN).
>
> I understand that number 2 is not your top priority, but someday you might
> find time for it .
>
> Thanks,
> Paal
>
>

[NoName]

Paal,
1) Already done (did it yesterday)
2) Is not a question of priority I am afraid, is a question of logical
integrity. For example asume the following:
aItems:= {"One", "Two", "Three"}; aItemsBound := { 1, 2, 3 }
If the user inputs "Four" or whatever, then nIndex should be zero and
ItemsBound is useless
Regards,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Mahanimann" <paaldalen@gmail.com> escribió en el mensaje
news:[email=474b4754@ozsrv2.ozlan.local...]474b4754@ozsrv2.ozlan.local...[/email]
>>> When utilizing the :nDataType=="dtBOUND" feature .AND. :nStyle ==
>>> csDROPDOWN
>>> the combobox buffer is updated with the field value (or the :aItemsBound
>>> value, I don't know) rather than the value from :aItems.
>
>> The field value. You MUST 'of course' use csDROPDOWNLIST in order to use
>> aItemsBound.
>
> Ok, then I put this on my wishlist:
>
> 1. Update the doc's on TComboBox:nStyle with a small note about this.
> 2. Make the dtBOUND feature available on editable TComboBox'es (:nStyle ==
> csDROPDOWN).
>
> I understand that number 2 is not your top priority, but someday you might
> find time for it .
>
> Thanks,
> Paal
>
>

[Mahanimann]

>> point is that when skipping down the browse (in VIEW-mode) using K_DOWN,
>> the browse dataset enters EDIT-mode automatically when reaching EOF().
>> Try it (in VIEW-mode, push K_DOWN when standing on the last row in the
>> browse), and watch what happens to the GET's and the TDBNavigator.
> Tried. Nothings happens at all. Sorry.
Very strange, it happens in all my versions: 1.65, 1.66 and 1.75-eval (on
different PC's) using the exact same sample i sent. I have "cleaned" the
project before recompiling in each version, so this is odd. But let's leave
it with that until v1.8 is here. If the behaviour is still there I'll make
a new sample or track the error.
Regards,
Paal

[Mahanimann]

>> point is that when skipping down the browse (in VIEW-mode) using K_DOWN,
>> the browse dataset enters EDIT-mode automatically when reaching EOF().
>> Try it (in VIEW-mode, push K_DOWN when standing on the last row in the
>> browse), and watch what happens to the GET's and the TDBNavigator.
> Tried. Nothings happens at all. Sorry.
Very strange, it happens in all my versions: 1.65, 1.66 and 1.75-eval (on
different PC's) using the exact same sample i sent. I have "cleaned" the
project before recompiling in each version, so this is odd. But let's leave
it with that until v1.8 is here. If the behaviour is still there I'll make
a new sample or track the error.
Regards,
Paal

[Mahanimann]

> 2) Is not a question of priority I am afraid, is a question of logical
> integrity. For example asume the following:
>
> aItems:= {"One", "Two", "Three"}; aItemsBound := { 1, 2, 3 }
>
> If the user inputs "Four" or whatever, then nIndex should be zero and
> ItemsBound is useless
Yes, unless there was a VALID clause (or ":lInputMustExcist and a
:cErrorMessageToDisplayWhenInputNotExcist" or ....many other things) denying
that. But I see your point and we can easily:-) do that on our own, so my
wish #2 is hereby wiped off the list.
Thanks,
Paal

[Mahanimann]

> 2) Is not a question of priority I am afraid, is a question of logical
> integrity. For example asume the following:
>
> aItems:= {"One", "Two", "Three"}; aItemsBound := { 1, 2, 3 }
>
> If the user inputs "Four" or whatever, then nIndex should be zero and
> ItemsBound is useless
Yes, unless there was a VALID clause (or ":lInputMustExcist and a
:cErrorMessageToDisplayWhenInputNotExcist" or ....many other things) denying
that. But I see your point and we can easily:-) do that on our own, so my
wish #2 is hereby wiped off the list.
Thanks,
Paal