List box refresh - Win 10 problem

[Canonian]

Through trial/error and lots of testing we have come to the conclusion that any computer with a fresh/clean install of Windows 10 (pre any updates CU or AU or after CU or AU updates) that an application written in VP9 SP2 works with the exception of refreshing a list box.

The interesting thing is the application works great by 14 people on Windows 10 (pre or after CU or AU), and here is the kicker:

On a fresh install of Windows 10 the application works great except refreshing a list box.
On on any computer upgraded from Windows 7 or 8 to Windows 10 (any version pre or post CU/AU) the application works perfectly including the list box refreshing. This is the VFP9 built in list box not a 3rd party ad-on.

There must be something that Win 7/8 had lingering that as allowing the program to work however on a clean install of Win 10 something is missing. We cannot figure it out, 3 days and still plugging away on the problem. After running out of things to try, I have removed and re-created the list box, put a button you can press to refresh the list box by simply clicking and still nothing works on a clean Win 10 install.

The program is a compiled EXE and the only external included file outside of native FoxPro components is "mscomct2.ocx" & "FoxyPreviewer.app". That is for the ActiveX Date Picker and FoxyPreviewer for PDF creation, and they both work on an upgrade or clean install of Win 10.

Anyone else having issues with programs on a Clean install of Win10 - any version?

 

[Mike Lewis]

Can you give us some more details about what you are seeing and what is going wrong.

What exactly are you doing when you see this problem? Are you calling the listbox's Refesh method? Or refreshing the entire form? And are sure you want to refresh it. If the underlying list has changed, then you usually need to call the Requry method rather than the Refresh. And, either way, what is actually going wrong? Are you seeing some sort of error? Or is it simply failing to refresh?

I'm sure we can help you, but you need to tell us more than that is simply doesn't work.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Canonian]

Sure.

The list box simply stays in its natural white state without displaying any information.

When you start the program you are presented with a screen full of information with edit boxes, check boxes, a grid, buttons and a list box. When you click on an item in the grid "left side, Vendor List", the click method fires and grabs some info from our Oracle SQL server and then displays that data in the list box. Pretty straight forward and simple. See the attached picture, the list box is the long horizontal white box middle of the screen with PO#, created columns etc..

What exactly am I doing:
REQUERY('existingpos') <- refreshed remote view with new data
thisform.frame.vendor.existingpos.requery <- refreshes the list
thisform.frame.vendor.exisTINGPOS.click <- this fires to update some info on the page related to the PO selected exisTINGPOS is the list box name.
thisform.refresh <- at the end


The box simply stays white as if it is empty. I had originally thought is was some strange video or rendering issue so I clicked on where an item would be in the list box to see its details, however nothing happened. So the list box is definitely not refreshing with data like it should - only on a Windows 10 clean install.

 

[Mike Lewis]

OK, that makes sense.

The next thing to establish is whether it is the requery of the listbox itself that is failing, or the requery of the remote view. You can check that by suspending the program after you execute [tt]REQUERY('existingpos')[/tt], and browsing the view to see if it contains data.

Then, if that's working as expected, suspend after the requery of the listbox to see if it is that that's failing or the form's refresh. (That said, you shouldn't need the form's refresh in order to see the updated listbox, so this might not be relevant.)

Although I can't say why the problem occurs in a new install under Windows 10, I'd be inclined to think it lies with the requerying of the remote view. An ODBC driver or a connection to a remote database is more operation system-specific than the refreshing a VFP control. (But that's just a guess at this stage.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Canonian]

Ok so I did something to test the REQUERY('existingpos') and simply put a browse command after. It fails on the Windows 10 clean install machine so there is something with REQUERY('existingpos')<- that is not working. The data on the form/screen shot is obtained from the Oracle Database, as a matter of fact I can change the data and it will write it back to the database. Something specific to the requery command is failing.

Progress.

 

[Canonian]

Ok so it is the REQUERY('existingpos') command.

I did this instead

USE
USE existingpos

and is works on the clean install of windows 10.

BTW existingpos is a remote view with parameters passed from the program upon refresh.

 

[Mike Lewis]

Yes, that's what I would expect. I don't know why the requery didn't work, but closing a view and opening it again does an implicit requery, so the effect is the same. Presumably there was something to do with the parameter passing that was causing the problem.

By the way, when you requery a remote view, it's often worth checking the value returned from the REQUERY() function. A returned value of 0 indicates that a problem has occurred.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

If a requery does not work most of the time there is some buffered change unsaved, a view requerry only is possible on a view with no buffered changes, so in case you use the view just to read values for picking from them in a listbox, a natural choice is to avoid the view to be updatable at all, setting it to not allow updates by using the view with NOUPDATE clause. or when having the remote view in a form dataenvironment set the ReadOnly property.

If you change that, you might be able to detect what causes a buffered change in the view data, what in turn doesn't allow the requery()

That said, it would not depend on Windows version directly, but Mike may be on the right track suspecting differences in the systems ODBC driver and connections where of course a missing connection would yield no data at all not even in the first run.

In a situation you want to allow modification of data you have to either tableupdate or tablerevert all buffered changes to have no pending buffered changes causing the requery to be rejected.

Bye, Olaf.

 

[Canonian]

Olaf,

There is probably a difference in the way ODBC reacts on Windows 10 because it works across the board on all other versions of Windows including Win 10 from an upgrade. There are no buffered or pending changes in the test data we are using. The requery command is returning a -1, no connection? I'd like to completely figure this out however the band-aid is in place.

thanks!