Problem with past into xbrowse numeric editable cell

[Marco Turco]

Hi all,
this is a self contained sample showing my problem,
pls. try to copy with the mouse this value: 123.123456
and past inside the xbrowse "value" cell., then press Enter and you will see the crazy value of 1.231235E8 !!!
Is it an xbrowse problem or do I have to manage the "past" format ?

Thank you
----

#include "FiveWin.ch"
#include "xbrowse.ch"

function Main()

local oDlg, oBrw

set decimals to 8

DEFINE DIALOG oDlg SIZE 400, 300

@ 0, 0 XBROWSE oBrw OF oDlg ARRAY { { "Romeo","London",123.990000 } }

ADD COLUMN TO XBROWSE oBrw DATA ARRAY ELEM 1;
HEADER "Name" SIZE 100
ADD COLUMN TO XBROWSE oBrw DATA ARRAY ELEM 2;
HEADER "City" SIZE 100
ADD COLUMN TO XBROWSE oBrw DATA ARRAY ELEM 3;
HEADER "Value" SIZE 100 PICTURE "@E 999.999999" EDITABLE

oBrw:CreateFromCode()

ACTIVATE DIALOG oDlg CENTER

return nil

[TimStone]

Marco,

On newer versions of xbrowse, that format has problems ( using the DEFINE and then ADD COLUMN ). I had used that hundreds of times in my application and all were broken. I had to recode every one of them to the newer, not yet documented, format.

Here is a sample of the newer format I was told to use. I am using a resource, but the same applies to your use. My first problem was with the column sizing, but your problem may also be a result of the formatting. Here is my new call:

Code: Select all  Expand view

REDEFINE  XBROWSE  oLBxcl ;
      DATASOURCE oClients  ;
      HEADERS "Account", "Client", "City", "Phone", "Cellular",  "Email", "Last Visti", "Total Sales" ;
      COLUMNS "acrnum", "clicom", "clicty", "clipho", "clicel", "clieml", "clidls", "acrytd"  ;
      ID 860 ;
      OF  oFldCSE:aDialogs[ 1 ];
      ON CHANGE  ( oClientsr:load(), oFldCSE:aDialogs[ 1 ]:update() )  ;
      ON DBLCLICK (  lCliScoped := oServiceUnits:ScopeUnits( oClientsr, lCliScoped ), oLbvm:refresh( ),;
            oServiceUnitsr:load( ), oFldCSE:aDialogs[2]:update( ),oFldCSE:setoption(2)   ) ;
      AUTOSORT UPDATE
 

[nageswaragunupudi]

Mr Marco

In effect you are trying to paste "123.123456" into a numeric GET which is formatted with European format "@E 999.999999". In this format "," is the decimal separator. When the value is pasted, the "." symbol is not considered as decimal. In effect you are pasting 123 million 123 thousands and 456. Naturally the value that is pasted can not be accommodated in the given picture format. If this is a simple GET, you will see "***.******".

When you assign/paste a higher value into an xbrowse cell and if the picture format can not display the full value, unlike Get, xbrowse does not lose the value. It still retains the value and tries to show in the best possible manner so that the user need not stare at meaningless stars. The value what you see is 123 million and odd represented in scientific notation.

Hope you now agree that:
1. This is a problem of pasting a huge value into a Get with picture clause meant to display a smaller value.
2. You think the problem is with xbrowse, because you are seeing it in an xbrowse and in fact xbrowse is innocent.
3. If it is a simple Get you lose both the original value as well as the pasted value. XBrowse behaves better by retaining the higher value and still trying to show it in the best-fit format within the assigned width of the column.

Correct way is to paste "123,123456" but not "123.123456".

[nageswaragunupudi]

Mr Tim

I have seen you have some other problems too. I shall to study and address all of them. Meanwhile it may please be appreciated that the problem reported Mr Marco is not a problem with xbrowse, whether newer or older versions.

[TimStone]

Mr. Rao,

In 33 years working with xbase programming, one thing always impresses me. Changes in one part of a program may always have unexpected results in another, and often the reason is not obvious. When I used to attend conferences, that was always a popular topic of discussion.

You will notice a common theme in my comments. I look for all the things that remain the same when something breaks. The item that changed is likely to be the problem. So, if my code does not change ( and has worked for years ) using FWH xx.xx, and then the next release of FWH suddenly does not work with it, the issue will be a change in the FW code. I always update to the latest release, so I can quickly know at what version the error started occurring. I also keep older versions so I can go back and be sure the program still works on the previous version.

The other thing I do is check the current documentation. I know people do not like to document. It is not the fun part of programming. ( I just rewrote hundreds of pages of documentation on my new version of my primary application. It's not fun, but it is important ). However, if I follow the documentation, I should be able to always avoid problems. So I always look there first. When I first ran into the column problem with xBrowse sizing ( it is still not right ), I checked the documentation. My coding matches it perfectly. However, you told me to use a different command format, which is not documented at all ... and it is still not there ... and so I rewrote hundreds of lines of code. Because of this, I had to ask more questions here which I would not have had to ask if the documentation was correct on the WIKI site.

I look forward to resolving those problems I mentioned above that still exist ( or which have returned ). There is another thread on column spacing that shares another perspective. Are you calculating column size from the content of the field or by the structure ( field width ). It has to be on the structure, and always has been in the past.

Tim

[Antonio Linares]

Tim,

> if the documentation was correct on the WIKI site

You are totally right. We need to update the WIKI.

Enrico, are you available to help us ?

[TimStone]

Antonio,

Here is one other thing about the website. In almost all cases, there is syntax for generated code ( ie. the @ x, @ y DEFINE structure ) and the Resource structure. This needs to be handled in xBrowse documentation also. I believe many of us are 98% resource users for COMMANDS.

Tim

[Enrico Maria Giordano]

You are totally right. We need to update the WIKI.

Enrico, are you available to help us ?

I'm not very good at writing docs.

EMG

[TimStone]

Antonio,

If we could get the Wiki updated so it accurately reflects the commands, that would be step one.

If we can do that, then I have a great Doc publishing tool, and I could see if I can import that info into a doc that can be added to what you distribute with the builds. We could also add some discussions in there about how to do things ...

If you go to www.AutoShopWriter.com and click on Support, then Manual, and click on the manual image, you can see an example of what I can do. In fact, I'm going to be adding videos into that manual also.

First step ... get the Wiki docs updated by those who work on various sections so it reflects the proper command and class calling procedures.

Tim

[Marco Turco]

Hi Rao,
I think it isn't just a get problem, if I try to past 11,123456 the acquired value in the xbrowse cell is 11,234560

[nageswaragunupudi]

Hi Rao,
I think it isn't just a get problem, if I try to past 11,123456 the acquired value in the xbrowse cell is 11,234560

I am not clear. Can you elaborate please?

[Marco Turco]

Hi Rao,
sorry, after further checks it seems only tget related