SetFldState and Cursors 1

[TheKen]

I want to use a cursor for an editable grid object. So I set MULTILOCKS ON, SELECT ... INTO CURSOR MyCursor READWRITE, and change buffering to 5 (optimistic table). When the user changes the WHERE condition, I repeat the SELECT but now the underlying table is different even though the alias is the same. That causes the grid to go bananas.

I read somewhere that I should ZAP my main cursor and APPEND from a temporary cursor for the new where. That works but now VFP thinks that everything's changed.

So, I try to run SetFldState(nFldNumb, 1, 'MyCursor') and get a "Function argument value, type, or count is invalid" error. Now, I'm going bananas. I've checked all variables to make sure that all parameters are correct. Any kind thoughts?

 

[bborissov]

Just before ZAP call TABLEREVERT(.t., "YourCursorAlias")

Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.

 

[Mike Lewis]

TheKen,

You could also remove the grid's RecordSource just before you do the SELECT, and re-instate it afterwards. That way, you shouldn't need to do the ZAP and APPEND.

The point is that the SELECT will destroy the cursor before it recreates it. If there is no cursor, the grid will lose its columns, including all the code and settings, which is what you are seeing.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[TheKen]

To bborisov, I tried TABLEREVERT() before the ZAP but it made no difference.

To Mike Lewis, I infer from your reply that trying to use cursors and SETFLDSTATE() is problematic and I should concentrate on workarounds. Is that correct?

 

[Mike Lewis]

I infer from your reply that trying to use cursors and SETFLDSTATE() is problematic and I should concentrate on workarounds. Is that correct?

Sorry, no. I was trying to address the problem of the grid going bananas, rather than the SETFLDSTATE() problem.

Let me get it right. The problem is that the user changes the criteria, you run a new SELECT, and the resulting cursor is (of course) different from what it was when you applied the buffering, so it looks like everything has changed. So you call SETFLDSTATE() to clear the changes, and that throws an error. Is that right?

The way I would handle this is to add three buttons to the form: Edit, Save, and Cancel.

The Edit button would enable the grid for editing, and - crucially - disable the user's ability to change the criteria. It would also do a SETFLDSTATE() to establish that the cursor is unchanged.

The Save button would check GETFLDSTATE(), do a TABLEUPDATE() if necessary, then disable the grid and enable the ability to change the criteria.

The Cancel button would do a TABLEREVERT(), then disable the grid and enable the ability to change the criteria.

Unfortunately, that doesn't solve your central problem of why SETFLDSTATE() was giving an error. Your syntax looks correct. The only thing I can think of is that nFldNumb does not hold a valid field number. Is that possible?

Also, I'm not completely sure the second parameter should be 1. Given that the "edit" you are trying to clear is in fact an append, I wonder if the parameter should be 3. But I'm really not sure about that.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[TheKen]

I'm just trying to understand cursors (not views nor CursorAdaptors nor grids) in conjunction with a Windows desktop application as I'm starting to use MySQL databases for files larger than 2 GB.

Imagine a simple Invoicing form. One possible design would be a pageframe as follows:
Page 1. Grid of Invoices allowing user lookup
Page 2. Invoice Details editing for Invoice No., Date, Supplier, etc.
Page 3. Invoice Items grid allowing user selection of any item
Page 4. Invoice Item Details editing for Part Invoiced, Quantity, Unit Price, etc.

Selecting a particular invoice in the grid on Page 1 automatically populates the fields on Page 2 and repopulates the grid on Page 3 for only those items associated with Page 2's invoice.

I'm trying to figure out how to make that work with cursors. The last step in getting that to work was the SETFLDSTATE() problem. In all of this massive effort and high art (I'd only double-checked and looked at the details umpty-fratz times), you hit on the tiny detail that eluded me: the setting must be 3 not 1.

Many, many thanks - I thought I was going bonkers.

 

[Mike Lewis]

TheKen, I'm glad I was able to suggest the solution - but I must admit it was a bit of a guess.

Your design looks sound, at a quick glance, and I agree that you're right to focus on cursors rather CursorAdapters. Cursors are useful - essential, even - throughout an application, and it's very useful to understand how they work.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business