Hi,

When I was last working with a grid, several months ago, I had it working fine; using beta.2.
The other day I started coding with FiC again, still beta.2, and I have found that the grid has stopped working!
Maybe I have changed some code somewhere, but I'm not sure what.

The problem is that, in addition to the normal columns that I add at runtime (Column1...Column8), there is now a column named Column0. I do not remember there being a Column0 previously.
What is also strange is that Column0 is identified as being inherited from the parent/base class, although there is no such object in any of the parent classes at design time.
Grid.ColumnCount is initially set to 0 and changed to 8 some time after the form init.

When I open the form with the grid for the first time there is no problem.
But the second time I receive this error :

awajax.lSuccess(.f.): Error detected at code line #12,562 of method 'awajax.propsrestore_props'
"awhtml.fxp!Awhtmlgen.grdrestore_() 
- Object 'COLUMN0' can't be found in Object {BaseClass: "Grid", ParentClass: "Dynamicgrid", Class: "Shopfloordynamicgrid", 
ClassLibrary:"h:\work\4manufacturing\classes\shopfloor.vcx", parent: stockcontrolcheckarea, attributesfield: "Attributes", 
autoinitialisewhennewrecordsource: .F., backcolourreadonly: 16244959, ...  

The trouble is that it seems that FiC has remembered that there is a Column0 and attempts to restore its properties the second time - however, although I can see Column0 via Intellisense the second time around, the Column0 object is a "zombie" (I have described something like this once before when public objects were restored) - by that I mean you cannot access the object in code, access its properties etc. Therefore Awhtmlgen.grdrestore_() crashes.

Do you have ideas about this?

I tried changing grid.ColumnCount to -1 initially, but I then get a different error instead the second time around :

awajax.lSuccess(.f.): Error detected at code line #12,562 of method 'awajax.propsrestore_props'
"awhtml.fxp!Awhtmlgen.grdrestore() 
- Method or procedure controlsource_assign(): error #1742 ("The data source for this object must be a variable reference") at code line #2,696
 ("this.ControlSource = Iif(NOT (Empty(m.tcCS) OR '.' $ m.tcCS OR Empty(m.this.Parent.RecordSource)) AND Used(m.this.Parent.RecordSource) , 
m.this.Parent.RecordSource + '.' + Alltrim(m.tcCS) , m.tcCS )")"

This time it appears that FiC has remembered that the recordsource cursor has 20 columns in it, but doesn't do the right thing when it tries to restore the controlsources to the 8 columns actually defined in the grid - for the 8th column it simply takes everything from the saved string to the right of | and assigns that to the controlsource of that column - the string of course contains lots of controlsources for all of the remaining 12 possible columns in the cursor.

So, I can't win at the moment!

Any advice much appreciated.
Paul

Hi Paul

Why did you set Grid.ColumnCount to 0 ? A grid without columns versus a grid.visible = .F. ?? I think it's better to set initially Grid.ColumnCount to 1 or 8...

Regards Gilles

Do you have ideas about .columnCount = 0? (at design time)

Like Gilles I prefer setting .columnCount to -1 and then set it in grid.Init() or the final number of columns

I tried changing grid.ColumnCount to -1…

1. With .ColumnCount=1, the grid takes Alias() at .Init() as .recordSource; reason why we always select 0 at the end of .Load()
2. However we need to fix the situation you describe; please try this:

modify command awHTML.prg
&& line 8,651
* luProp = Iif(m.liProp = m.toGr_.ColumnCount; && 2019-11-07 thn -- {FiC V 2.30.0-beta.5} {en} replaced
*	, Substrc(m.luNode, m.liFrom + 1);
*	, Substrc(m.luNode, m.liFrom + 1, At_c('|', m.luNode_, m.liProp) - m.liFrom - 1);
*	)
luProp = Substrc(m.luNode, m.liFrom + 1, Evl(At_c('|', m.luNode_, m.liProp), Lenc(m.luNode)+1) - m.liFrom-1) && 2019-11-07 thn -- {FiC V 2.30.0-beta.5} {en} replacement

With that code-fix I can now set to -1 and the grid is working.

Thank you.
Paul

Hi,

Well, not always working...
For the past few weeks I have not had the Column0 error, but today I switched to COM mode and saw it happening a couple of times - and then it went away again (for now).

I wonder if it is linked to the formname.ini.dbf file.
In there I see a record for the grid (Pn = "GRIDRS") and the Pv column contains this :

<ControlSource>SHOPFLOORUICHECKAREASTOCK.bomid|SHOPFLOORUICHECKAREASTOCK.bomrevision|
SHOPFLOORUICHECKAREASTOCK.bomtype|SHOPFLOORUICHECKAREASTOCK.entityid|SHOPFLOORUICHECKAREASTOCK.branchid|
SHOPFLOORUICHECKAREASTOCK.areaid|SHOPFLOORUICHECKAREASTOCK.locationid|SHOPFLOORUICHECKAREASTOCK.trackingunit1|
SHOPFLOORUICHECKAREASTOCK.trackingunit2|SHOPFLOORUICHECKAREASTOCK.trackingunit3|
SHOPFLOORUICHECKAREASTOCK.trackingunit4|SHOPFLOORUICHECKAREASTOCK.bombatch|SHOPFLOORUICHECKAREASTOCK.bomserial|
SHOPFLOORUICHECKAREASTOCK.quantity1|SHOPFLOORUICHECKAREASTOCK.quantity2|SHOPFLOORUICHECKAREASTOCK.quantity3|
SHOPFLOORUICHECKAREASTOCK.status|SHOPFLOORUICHECKAREASTOCK.expirydate|SHOPFLOORUICHECKAREASTOCK.trackedcost|
SHOPFLOORUICHECKAREASTOCK.umid|SHOPFLOORUICHECKAREASTOCK.packdate|SHOPFLOORUICHECKAREASTOCK.packhouseid|
SHOPFLOORUICHECKAREASTOCK.stationid|SHOPFLOORUICHECKAREASTOCK.madebyid|SHOPFLOORUICHECKAREASTOCK.madedate|
SHOPFLOORUICHECKAREASTOCK.quantity|SHOPFLOORUICHECKAREASTOCK.bomdescription|SHOPFLOORUICHECKAREASTOCK.selected|
SHOPFLOORUICHECKAREASTOCK.selectedquantity|SHOPFLOORUICHECKAREASTOCK.lastcheckeddate|
SHOPFLOORUICHECKAREASTOCK.lastcheckedquantity|SHOPFLOORUICHECKAREASTOCK.ischecksuperseded</ControlSource>

<ColumnCount>32</ColumnCount>

<Columns>"0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31"</Columns>

This has presumbly been generated when the form was instantiated and grid.ColumnCount = -1. Later on there are only 8 columns in the grid.
What I am wondering is if <Columns>"0 is causing the phantom Column0 (even though the Members element contains Column1...Column32) ?

I also wonder if that information held in formname.ini.dbf should be updated when the ColumnCount is changed, or maybe it doesn't matter.

Thanks
Paul

This has presumably been generated when the form was instantiated and grid.ColumnCount = -1. Later on there are only 8 columns in the grid.

If you select 0 at the end of form.load()and make sure that no control.Init() selects an alias, the grid will not auto-create columns. Alias() should be set in form.Init()

What I am wondering is if <Columns>"0 is causing the phantom Column0 (even though the Members element contains Column1...Column32) ?

Columns are numbered in base 0 for use in generated JavaScript.
FoxInCloud stores the names of the columns and re-assign the same name in case of a dynamic grid where .columnCount changes across users.
So Column0 must have been assigned by VFP or at design time (for whatever reason). We'll probably need a remote session to understand the exact scenario and debug it.

I also wonder if that information held in formname.ini.dbf should be updated when the ColumnCount is changed, or maybe it doesn't matter.

formname.ini.dbf stores the initial state of the form (just after .wlInitFirst), consistent with the generated HTML, and provides the reference against which the changes are determined after form.Init()