Hello Antonio,
Maybe there is an error in the paintdata method.
The 8.06 version does not work if you pass a numeric value.
Regards,
Otto
PAINTDATA method
if ::bStrData != nil
cData := Eval( ::bStrData )
msginfo( cData)
if ! Empty( ::nDataStrAlign )
cData := AllTrim( cData )
endif
Application
===========
Path and name: C:\xWinhotel\xWINHOTEL.exe (32 bits)
Size: 2,951,168 bytes
Time from start: 0 hours 0 mins 40 secs
Error occurred at: 04.07.2008, 17:28:20
Error description: Error BASE/2022 Argument error: ALLTRIM
Args:
[ 1] = N 14534
Stack Calls
===========
Called from: => ALLTRIM(0)
Called from: .\XBROWSE.PRG => TXBRWCOLUMN:PAINTDATA(5574)
Called from: .\XBROWSE.PRG => TXBROWSE:PAINT(1018)
Called from: .\XBROWSE.PRG => TXBROWSE:DISPLAY(804)
Called from: CONTROL.PRG => TXBROWSE:HANDLEEVENT(0)
Called from: WINDOW.PRG => _FWH(0)
Called from: => MSGINFO(0)
Called from: .\XBROWSE.PRG => TXBRWCOLUMN:PAINTDATA(5567)
Called from: .\XBROWSE.PRG => TXBROWSE:PAINT(1018)
Called from: .\XBROWSE.PRG => TXBROWSE:DISPLAY(804)
xBrowser - maybe an error
Alltrim on Numeric Fields ?
Hello Otto,
it seems, you try a alltrim on a numeric-field ?
Best regards
Uwe
it seems, you try a alltrim on a numeric-field ?
Best regards
Uwe
Since 1995 ( the first release of FW 1.9 )
i work with FW.
If you have any questions about special functions, maybe i can help.
i work with FW.
If you have any questions about special functions, maybe i can help.
AllTrim( cData ) in xBrowse.prg
Hello Otto,
I found the part in xBrowse.prg
It seems, the var-type is not checked.
What happens, when you use val-types < D > and < L > ?
( in the moment, i'm still working with 8.05 on the main-computer.
8.06 is on the 2. computer for testing. )
found in xBrowse.prg Vers. 8.06
( maybe VALTYPE must be added ? )
Regards
Uwe
I found the part in xBrowse.prg
It seems, the var-type is not checked.
What happens, when you use val-types < D > and < L > ?
( in the moment, i'm still working with 8.05 on the main-computer.
8.06 is on the 2. computer for testing. )
found in xBrowse.prg Vers. 8.06
( maybe VALTYPE must be added ? )
Code: Select all
if ::bStrData != nil
cData := Eval( ::bStrData )
if ! Empty( ::nDataStrAlign ) .and. VALTYPE( cData ) = "C"
cData := AllTrim( cData ) // line 5596 !!!
endif
if isrtf( cData )
cData := "<RichText>"
endif
else
cData := ""
endif
...
...
Uwe
Since 1995 ( the first release of FW 1.9 )
i work with FW.
If you have any questions about special functions, maybe i can help.
i work with FW.
If you have any questions about special functions, maybe i can help.
- Antonio Linares
- Site Admin
- Posts: 37481
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Contact:
This is not a bug. This is the intended behaviour.
If you directly assign a value to bStrData, the codeblock should compulsarily evaluate to a character value only. From the time xbrowse was first published, bStrData is supposed to evaluate to a character value only and that will remain like that in future also. It is intentional that if the codeblock evaluates to any other datatype, it results in a runtime error, pointing out the programming mistake. This is so with all the browses.
It is only xbrowse that gives the flexibility to use codeblocks evaluating to any datatype, but that is by assigining the codeblock to bEditValue, but not bStrData. XBrowse altuomatically creates bStrData codeblock, converting the result to a character value, using cEditPicture, if given.
As already documented in the earlier versions, direct use of bStrData is deprecated. You may use bEditValue and optionally also cEditPicture and leave the bStrData uninitialized. XBrowse automatically creates a codeblock for bStrData using the bEditValue and cEditPicture.
However, if you prefer the old style, you can sitll assign a codeblock returning character value to bStrData. That option will always be there with full backward compatibility.
We also encourage use of the new command syntax, which greatly simplifies a lot coding and avoids any uninteded bugs / mistakes in the code. But still the option is yours.
If you directly assign a value to bStrData, the codeblock should compulsarily evaluate to a character value only. From the time xbrowse was first published, bStrData is supposed to evaluate to a character value only and that will remain like that in future also. It is intentional that if the codeblock evaluates to any other datatype, it results in a runtime error, pointing out the programming mistake. This is so with all the browses.
It is only xbrowse that gives the flexibility to use codeblocks evaluating to any datatype, but that is by assigining the codeblock to bEditValue, but not bStrData. XBrowse altuomatically creates bStrData codeblock, converting the result to a character value, using cEditPicture, if given.
As already documented in the earlier versions, direct use of bStrData is deprecated. You may use bEditValue and optionally also cEditPicture and leave the bStrData uninitialized. XBrowse automatically creates a codeblock for bStrData using the bEditValue and cEditPicture.
However, if you prefer the old style, you can sitll assign a codeblock returning character value to bStrData. That option will always be there with full backward compatibility.
We also encourage use of the new command syntax, which greatly simplifies a lot coding and avoids any uninteded bugs / mistakes in the code. But still the option is yours.