xBrowse - Dates - FWH 2310

[TimStone]

You will love this one.

A client notified me this morning about a problem. I am waiting to hear about his computer and windows version, but here is what I have found:

First, the code for the xbrowse using a resource

Code: Select all  Expand view  RUN

    REDEFINE XBROWSE oLbxo  ;
    DATASOURCE ::oOrders  ;
    HEADERS " Done ", "Paid",  "Type", "W/O #", "Company", sLbl[4], sLbl[1], "Due Date", "Time",  " Started ", " Paid ", " Status " ;
    COLUMNS "ordnot", "Totals", "status", "wrkord", "ordcom","vehlic", "ordveh", "duedat", "duetim",  "wrkdat", "paydat", "CliUs1"  ;
    JUSTIFY  ,,2,2,,,2,2,2 ;
    ID 390 OF  oWdlg ;
    ON DBLCLICK ( ::oWorkOrder:FullEdit( ::oOrders, oWdlg ),  oLbxo:update(), oOrderList:LoadDisplayValues(  ), oWdlg:update()) ;
        ON CHANGE ( oOrderList:LoadDisplayValues( ), oWdlg:update() ) ;
        AUTOSORT UPDATE

 

duedat, wrkdat, and paydat are all Date fields in the file.

wrkdat displays as "999999" while the others display as normal dates.

On my Windows 64 bit, Version 11, 23H2 OS, ALL dates display correctly. On my Virtual machine ( Parallels, on an Mac Mini with ARM processor ), the wrkdat displays incorrectly.

This occurs on a few other xbrowse controls, and it is consistent. I see it on the same locations where he sees it.

Any thoughts on this ? It is only in the latest FWH 2310 release ( downloaded after the last fixes ).

[nageswaragunupudi]

I assume ::oOrders is a Database Object. Please confirm.

wrkdat displays as "999999" while the others display as normal dates.

This happens if oCol:cEditPicture of this column is "999999". XBrowse builds the picture from that column's cDataType, nDataLen and nDataDec. In turn, XBrowse takes this informatin from ::oOrders:aStruct. It appears that XBrowse is reading the structure of the field 'wrkdat' from ::oorders as { "WRKDAT", "N", 6, 0 }. Surprising.

We can get away with suggesting a work-around

Code: Select all  Expand view  RUN

oLbxo:oCol( 10 ):cEditPicture := nil

But that is not the point.

We need to understand why 'wrkdat' field's structure is read wrongly. More surprising is that this is behaving differently on different PCs (configurations) and also differently between FWH2307 and 2310. Right now, I can not figure out whats happening differently on different computers.

We need your help in understanding this problem.

1) Before defining the xbrowse, insert a line of code:

Code: Select all  Expand view  RUN

XBROWSER ::oOrders:aStruct

Please see what you see for the field "WRKDAT" on both PCs (with problem and without problem) and let us know.

2) Insert this code after defining the XBrowse.

Code: Select all  Expand view  RUN

oLbxo:bRClicked := <||
    ? oLbxo:oCol( 10 ):cExpr,oLbxo:oCol( 10 ):cDataType, oLbxo:oCol( 10 ):cEditPicture
        return nil
    >
 

Then right click on the browse and let us know what you see. What diffeences you see on PCs that show correctly and incorrectly.

Sorry, but we have to give you this trouble to understand the real issue.

[TimStone]

No problem. It is late but I will do those steps in the morning. Yes, it is strange, and unique, so I’m happy to do those tests.

The one client who had problems is running OS 21H2, so I asked him to run the Windows update.


Sent from my iPhone using Tapatalk

[TimStone]

Good Morning,

I have run that on both computers.

On both computers xbrowser shows wrkdat as D 8

On the i7 computer, the right click displays wrkdat D

On the Virtual machine, the right click displays wrkdat D 999999

To clarify, although the dates are different for entries of wrkdat, the incorrect display shows 999999 for ALL rows regardless of the content of the wrkdat field.

I've also just encountered another issue with xBrowse but need to do further testing to be sure exactly what is happening.

Tim

[nageswaragunupudi]

On the i7 computer, the right click displays wrkdat D

On the Virtual machine, the right click displays wrkdat D 999999

This difference is surprising.
Can you take some more trouble and test it with program built with 2307 ?
We need to understand why is this difference between i7 pc and the virtual machine.

PS: We can provide you with a revised version to display correctly. But that is only a kind of workaroind.
What we really need to find out is why is the above difference.
Please help us

[TimStone]

I did build with FWH 12.07 and now it shows the same issue.

On the ARM machine ... it shows on the aStructure ... WRKDAT, D, 8, 0, , , 999999
On the i7 is shows as WRKDAT, D, 8, 0, , , , so no 999999

Just to be sure, I copied the entire data directory from the known good to the problem system and thus the files were exactly the same on both computers. Same problem

Finally I copied all of the files from the directory where the .exe resides, including .dll files, and suddenly it worked.

So ... my first step is to see if I can isolate exactly what .dll file might have been different.

[nageswaragunupudi]

On the ARM machine ... it shows on the aStructure ... WRKDAT, D, 8, 0, , , 999999
On the i7 is shows as WRKDAT, D, 8, 0, , , , so no 999999

This has nothing to do with your files/databases
1. This problem was there in 2307 also and still continues. Am I right?
2. In that case , even with 2307, xbrowse must be displaying '999999' in the WRKDAT column on ARM machine. Right?

In our software, the picture clauses are built by database.prg and then used by xbrowse.
We need to find out why database.prg is working differently on different machines.

Again, this has nothing to do with your dbf files.

[TimStone]

Unfortunately, I think it got more complicated than that. First, clients who have the problem were not using ARM computers. I was able to see the problem using mine ( C2 below ).

Computer 1 ( C1) is my primary programming computer. I am running Windows 11, 23H2. Builds are done with Harbour ( 32 & 64 ), FWH ( latest versions ), and Microsoft Visual Studio Community ( latest builds ). It is a Dell Inspiron AIO.

Computer 2 ( C2 ) is a Mac mini, using the M2 processor ( ARM ). It has Parallels running Windows 11, 22H2 in a VM.

The data is stored in a MLS12s folder on the "server" which could be any type of machine, or for a single install ( not multi user ), it is on the same machine.

The Client consists of an .EXE, and multiple supporting files ( .lic, .ini, .dll, etc. ) placed in the MLS12c directory

I built the application and placed the primary .EXE in the MLS12c folder

1. I never observed the problem on C1, but did see it occur consistently on C2 using the exact same .EXE.
2. I did not see it with earlier builds using FWH1207. It did occur with 1210
3. I rebuilt the application using FWH 1207. The problem did not occur on C1, but did occur on C2
4. I then copied all of the data files from C1 to C2 so I could be sure it wasn't in a data file. I still got the same result with the error on C2
5. Finally I took all of the remaining files in the MLS12c folder ( Client ) and copied them from C1 to C2. Then the problem no longer occurred.

My mistake was that I did not first compare the two sets of files to see what was different. I do not appear to have a copy of the original set. I just know when I copied over those files, the problems went away.

So, now I'm trying to see if I have the set somewhere where I can compare the new vs the old ...

Meanwhile, people are getting automatic updates applied by Microsoft to their OSs. One client called to tell me he could no longer Cut and Paste in our program. It occurred a couple of days ago when I sent out the first update. When I asked him specifically where, he went back to check and it was suddenly working. He then remembered that Microsoft Updates were being applied in there also .... so it does get very hard to dig into this.

With all of that in mind, I'm quite happy to do any tests you might like ...

[Antonio Linares]

Dear Tim,

Is the problem solved ?

It seems as you missed to copy something. Is it so ?

[TimStone]

Antonio,

The problem is no longer on my ARM machine.

However, my client says it is still on his Intel i7 Computer. That makes it even more complicated.

It is not that I missed to copy a file. It must be that some .dll on there wasn't current. However, those are fairly new installs ( within past 60 days ), and using all of the current install files, it also works on the ARM. So this is really tricky to solve.

Of course, we expect that with software .... and Windows

Tim

[Antonio Linares]

Dear Tim,

> However, my client says it is still on his Intel i7 Computer

Is it an apple computer ?

If not, what Windows version is he using ?

[TimStone]

OK ... I HAVE ISOLATED THE PROBLEM.

Many of my clients, and some of my test machines, use Advantage Data Base Server. That is the root of this problem.

If I go to our DBFCDX RDD, absolutely no problem. If I turn on ADS LOCAL or REMOTE, using the ADS drivers ( all versions ), the problem described in the original post will occur.

I think I'll have to use a workaround to avoid this. I have many clients who use ADS Client Server, and paid a lot for the licenses. The product has not been updated since 2015, it is now end of life, and the company will not release it, nor do they provide an alternative. So there is no way to get any adjustment or fixes to that software, and we don't have a DBF supporting alternative.

I don't know if we can address this through a tDatabase update, or if it is more than that.

Tim

[nageswaragunupudi]

If the problem is with ADS, let us now test dbfs with ADS.
Meanwhile please download the latest build of FWH again.
We will proceed testing dbfs + tdatabase using ADS.
We "have" to make the class working perfectly with ADS also.
I will do some tests tomorrow here.

[TimStone]

The files I have downloaded now are from 11/4 at about 11:30 am. Is there a more recent version ?

[Antonio Linares]

Dear Tim,

Yes, please download FWH again