Windows 11 - any problems noted? 1

[GriffMG]

I just upgraded my lappie to W11, thinking that customers will be pushed to do so soon - as with W10, and not wanting any unforeseen issues to bite me!

I cannot see anything life threatening... any gotchas I should be looking for? like the fix for general fields required in W10?

 

[herbstgy]

I just upgraded recently, too... so far, it works surprisingly well!
and it's easier on the eyes than W10 in my opinion.
anyway, you might wanna check this, if you don't want it to talk behind your back:

O&O ShutUp10++ - O&O Software GmbH

www.oo-software.com

 

[GriffMG]

I have spotted that ver brings up windows 10, and winver windows 11

 

[Paul Gibson]

For us, we've supported our applications on Windows 11 for as long as it's been out and I only know of one issue that appeared to be unique to Windows 11 and that was a laggy OS problem regarding generating a file. This particular issue could have been due to Adobe rather than Windows 11 but the problem only existed for Windows 11, no Windows 10 or previous OS showed this problem. I'll try to briefly describe it...

Our VFP application has used Adobe integration to generate PDFs for well over a decade, maybe even two decades. It uses the method where it runs the VFP report, specifically pointing to the "Adobe PDF" software printer and this generates a PostScript (PS) file. When the first-step is complete the integration continues, taking the PS file and automating the Adobe Distiller to convert the PS file to a PDF file and that's it.

I know there are probably other, potentially better, ways to generate PDFs from VFP - we actually do also use FoxyPreviewer (FP) - but this Adobe method has been working for much longer than we ever had access to FP so plenty of users do use that method.

Anyway, that 2-step process generally works fine, as long as the Adobe components are correctly installed, licensed and the settings configured. On some Windows 11 machines, not all I hasten to add, the issue we had was that the first step had a significant lag where the command to generate the report as a PS file completed, returning control to the VFP program to proceed to the following code lines, but the PS file would not actually show up in the destination folder for some extra time. It was never long, maybe not even a second, potentially just a few dozen milliseconds perhaps but whatever the delay, it was big enough to break the two-step process. Computers are fast so if the REPORT command completes, then moves onto lines which check if the PS file exists and the file hasn't arrived in the folder yet, because of the lag, then that's a problem.

The user experience of the problem was that they would try to generate the PDFs and they'd always get the message that the system was unable to generate the PS file but if I checked their machine the PS file would exist and that's how we worked out that the PS file was being generated but the file lag was causing the program to check for the files existence before the file existed.

The solution was simple, we had to code a "check for file and wait a bit" loop routine so instead of just a simple FILE() or ADIR() check it would go into the routine that would check for the file and if it didn't exist, just do a short wait, like 100 milliseconds, check again and while the file can't be found keep looping for a set time limit, like 2 seconds. Only after the limit has been exceeded then return that the file failed to be created but if it did create (and it generally does) within that limit then proceed as normal.

As said, we only had to employ this method after some of our users started reporting the problem and every single report of the problem was on Windows 11, without fail. It's just standard practice now, that PDF generation procedure always uses the "check and wait if" routine instead of instantly checking and potentially failing.

Other than that I can't think of anything else that Windows 11 made us do differently.

 

[GriffMG]

Thank you Paul

 

[Gary Sutherland]

I've found the screen scaling messes with the positioning when sizing forms, etc, when programming.

 

[Piotr Czekalski]

In VFP 6.0 the "$" clause was causing problems for one of my clients.

X="A"
IF X$"ABCD"

EndIF

I replaced it with Inlist()

Maybe it was a special case. I don't remember the details. It was about a year ago.

I confirm necessity of using 100,200 millisecond slowdowns for File() and ADir() to check if a file or folder has been generated (regardless of Windows version).
I expect problems with handling DBF tables in a Microsoft Windows server environment. I had problems when changing Windows 7 to Windows 10. On Linux servers is OK .... as always ;-)

 

[Dan Olsson]

I have about 150 clients at about 40 different places in Sweden.
All have the same setup with the program and data on a server share.
ONE of those clients was upgraded(?) to W11 and she immediately complained that everything got very slow. Everything worked but took some 3-4 times longer to do. I mailed everyone and warned them about the problem. I never resolved why

 

[Piotr Czekalski]

Dan, it may be a coincidence. Maybe it's the network switch's fault. In my case, 99% of network speed problems are caused by network switch failures. Another reason is incorrect network card configuration. I don't know much about this, but maybe Windows 11 has configured the card incorrectly? Maybe it has changed the network transmission speed to slow ?

 

[GriffMG]

I have noticed one thing, since I upgraded the BSD has appeared twice already... it had largely stopped some time ago when I upped the RAM to 64GB

 

[tomk3]

We do not have problems (yet ) , except :
Windows 11 has an option "windows may change default printer". We recommend to disable that if you have little label printers and A4 printers and create PDFs via Foxyprviewer.

 

[Chris Miller]

I don't see anything really new here.

How could $ can even be OS related? No offence, I have had similar problems once with VARTYPE() to be fixed by using TYPE() instead in VFP6/7, I do believe you actually had the problem, therefore, but it can't be OS related, $ just like TYPE() and VARTYPE() have nothing to do with the OS, VFP doesn't use any OS API functions for these VFP operators and functions, so there can't be an OS dependency.

OS() itself has no parameters in VFP6, but in later versions offers better OS version details. Nevertheless,even the VFP imaging blog had an article on that: https://vfpimaging.blogspot.com/2021/04/getting-correct-windows-version-os.html
There are more options, like a WMI query of Win32_OperatingSystem.

That you don't directly detect file existance in VFP has been a problem discovered using PACK since Windows Vista, which you therefore better replace with code copying the data into a cursor, ZAP the DBF and APPEND from DBF("cursorname") or more safe options using a backup and temp table DBF file (safe against power outage). Anything creating files by a second process also is treated best by waiting for the file and maybe up to the point you can fopen it with write permission.

Windows default printer automatic change feature I think I know since Win10.

Network card and switch not negotiating the best transfer rate is a network thing and was always a problem, if it's misconfigured, outsie of any OS or VFP dependency. If you have a problem there it's more likely due to a new and not optimized erver than due to clients.
Then within the network performance there's the opportunistic locks problem that can come back with client/server changes, as you lose the registry entries controlling the damage and forget to reapply them. Or even need a new set of reg keys. Maybe that's due now or soon.

BSD, well, that's surely OS and Hardware. Long time no see, for me. I take it from here Win11 needs large RAM. No big surprise to me, though I had the impression MS was rolling back on Hardware demands also for graphics, because of the change from Aero to flat design, too.

So the only thing I consider a new problem in recent times was default printer and the general field problem under Win10. Whereas avoiding general fields was recommended since at least the times of Win XP, it's always a bad idea for images, you would therefore only need it for other OLE objects like RTF Text, I think there's a well known way to use RTF in VFP reports with a general field and olebound, i.e. olecontrol within a report. There's the only need and only terporary need for general fields for things like that in reports. And that was a bummer within Win10, as it didn't even worked for that temporary usage. The core problem usually was that ole servers are not the same across Windows versions, if you used general fields to persist data and then use it on a new OS, but that was recommended against for very long, already. Up to Win11 you never had this problem within the same client using general fields for OLE objects locally and termporarily, though.

The default printer doesn't bite you, if you go bya the well known mehanism of installing a printer driver with a dedicated name, also to manage differrent configurations, different paper trays to use, for example, and the SET PRINTER TO NAME knownname instead of using the default printer.

 

[ManniB]

One issue to be aware of is that the Printer menu on Windows 11 changed and has some flaws.

See this topic:

Windows 11 Bug in Print Dialog | Foxite

You can activate the Legacy Print Dialog but that also comes with problems as the number of copies and some other options are ignored.

So it's important to check if your methods of choosing a printer and different print options work as desired on Windows 11 and apply changes, when needed.

Regards,
Manni

 

[GriffMG]

My BSD looks like it is related to a crypto package I use, upgraded (after 11 years) last night and all seems better...

 

[Chris Miller]

Manni,

just don't use the File->Print menu. If you go by recommendation of printers installed by known names (even multiple times for different configurations) you give users a choice from APRINTERS or even only use the known printername you first set by SET PRINTER TO NAME knwnname (or picked name) and REPORT FORM directly or with preview but skip this dialog of printer choice. I.e. i you do a menu with the quick menu option, just delete the _mfi_sysprint menu item from the file menu.
Also remove the printer from the report (or in VFP9 simply untick the "save printer environment". The latter is a recommendation for over 20 years, IIRC and the idea of printer setting preconfigured with whatever detail dialog the printer vendor offers with his drivers is also 15-20 years old. There are obviously always situations a predefined printer is fine, but then you would also not want to let users pick another printer, usually, if a report is very bound to a specific printer.

The point about number of copies not taking effect may be something to watch out, can obvioulsy also be done without usage of the system printer choice dialog.

BY the way and related to that: Sys(1037), the SYS function to start the systems page setup dialog also changed working as normal since Vista and there were workarounds for that, too. You also have the Windows API for printer queue and print job controlling, you can make yourself independent from these things, if you are willing to put a bit of effort in the preparation of printer setups you then use by name only. It's easier if you program for a company and have such things under control for domain clients, but this way works very fine for a decade and longer, too. As said it also doesn't depend on whether the default printer is under your or your users control or not and whether Windows takes control and changes it, if you specify a printer by SET PRINTER TO NAME, the next REPORT FORM run prints to that printer, unless you have saved printer environment into the FRX that overrides that.

 

[Piotr Czekalski]

I don't see anything really new here.

How could $ can even be OS related? No offence, I have had similar problems once with VARTYPE() to be fixed by using TYPE() instead in VFP6/7, I do believe you actually had the problem, therefore, but it can't be OS related, $ just like TYPE() and VARTYPE() have nothing to do with the OS, VFP doesn't use any OS API functions for these VFP operators and functions, so there can't be an OS dependency.

The problem is that the "$" operator worked in the program code from 10-15 years and suddenly stopped working properly when system was changing. I understand that it was an coincidence.

A friend of mine, a computer genius, used to say in such cases that it is due to changes in the ambient temperature and humidity.


From more interesting cases I had.

Computer was standing on the desk, and I was correcting the program that printed the report (VFP6). Everything was OK. When computer was placed under the desk then priter error occurred. Some typical VFP error message. When computer again was placed on the desk, report was printed without errors. Correcting cables did not help. It turned out that there was radiator under the desk, that was supposed to heat the room. Putting the computer next to the radiator (15-20 cm) caused the system to act like a capacitor. The electrostatic field caused such strange interference. That's what electrician said. I remember because I was looking for an error in program code and had to stay on a business trip for another day. We "talked" with electrician all night. In the morning I had a headache like never before from this "conversation" of course

The cause of the incorrect operation of the "$" operator will no longer be solved .... thanks to the use of INLIST()

I had a few such strange situations. Some led to termination of contracts. Clients lacked patience ...

 

[Chris Miller]

I agree to that aspect: If you have a workaround, use it, there's no advantage to insist that something should work, as I said in the VARTYPE case I used TYPE instead. It never occurred again and a long way from then with both OS and VFP version changes, there was no problem using VARTYPE, again.

I just don't think of those things as worth putting into a general bug list, it's just absurd.

By the way, there are simple cases where its forseeable the $ operator won't give the same result as inlist:

? InList("ab","abc","def","ghi")
? "ab" $ "abc,def,ghi"

If you cater for that by using a comma within the leftside operand "ab," $ "abc,def,ghi" you still fail with false positives for "ef," $ "abc,def,ghi" and even going for ",ab," $ ",abc,def,ghi," such usage of the $ operator only stays similar to inlist when the actual serach term, the "ab" is not containing commas. The $ is not the same as inlist, in short. My bets would be on having had such a case, and I'm not free of fails in this scenario or similar based on instring search or the way string comparisons work in general. In that case, changing to INLIST is even the best move you can make, even though it has limits in the number of elements, which $ does not have.

 

[Piotr Czekalski]

Inlist() is a bit more difficult to parameterize than the "$" operator if the dependencies are created dynamically. In a text variable I had to build the function syntax dynamically and run it as Evalu(). In my case, these were symbols of employee groups in a payroll program. "A" - Administration, "B" - Pedagogues, "E" - Guards, "G" - Cooks, etc. These were single characters. A program is working in a prison. A very interesting place. Once, the prisoners mistook me for a journalist from Big Brother. I had a Toshiba Satellite Pro laptop. The prisoners said that as part of an experiment, I had allowed myself to be locked up in prison and was connecting to a TV studio via satellite