Expression evaluate to an illegal value

[Nro]

I have a new problem with one of my clients. They install a fresh new Windows 11 version on a laptop. and now, the user received a message when he access some screen (sorry, the message was in French so I tried to translate it)

Error #: 2005
Message: Error loading file - record n° 115. lblInterne < or one of its members >. FontCharSet : Error with lblInterne - FontCharSet : Expression evaluates to an illegal value
Line: 23
Code:
Method: C_INVOIC

It seems to appear for one label in particular, so I delete the label, but I receive the same message for a container. It’s not the only screen, I also received this message on other screen so it’s not a corruption. It’s not the only Win 11 machine at my client place and the working.

 

[Chris Miller]

Well, what is FontCharset in your development project?

Usually, you don't touch that and mostly - unless your system would be something like Chinese, Japanese, Vietnamese, Indian, with non-latin characters - you'd set this, otherwise it would stay at the default 1 for Western scripts of Latin fonts.

If you look into the help topic it says it depends on the OS, too.
Quoe:

The operating system and font determine the default setting for FontCharSet

.

In usual versions since XP multiple language support is normal, In French Windows, I'd also expect support for Western languages and Latin character sets. It's very unusual this doesn't work, so have you set this off norm, if only by accident?

Even if it is Western, do you use specific fonts? If so, your EXE has a dependency on them and you have to distribute them with your software, too. I can imagine the set of fonts in Windows has changed in Windows 11, there are always some such changes, so using some more standard fonts like Times New Roman, Arial and maybe Courier New could also help overcome the problem.

Chriss

 

[Chris Miller]

One common case it could be that would be off the norm is fonts for barcode support. Well, do you use a barcode library that needs some sepcial font and did you forget to provide that?

Chriss

 

[Nro]

Thanks Chris for these suggestions. I thought it was a problem with the FontCharSet but even with a container I got the error. The FontCharSet I use is '1 - Western' and all my labels in the application are working fine.

 

[Chris Miller]

Well, forms also have that property, but you're right, not containers.

Are you sure you have exactly the same message for a container, then?

What I mean by that is one of several things. As such error messages about records of a scx or vcx files can be about the object the record is or [highlight #FCE94F]one of its members[/highlight] and then the error could also be in the base class if that container isn't just a native base class container. It also seems to me you're not getting this in your project during tests, only on their system and you might only have partial information.

The object in the record number might also differ from what you have in your current development version of the project. This means all you can do is rebuild, freeze your project state by making a copy you don't touch, and let them reproduce the error by starting that form to know which record really has that error.

Chriss

 

[Nro]

One on my problem is that I can’t reproduce the error anywhere, except on her machine. I think I’ll ask them to reinstall Windows and do a progressive install of other apps and test after each installation. Thaks for your help.

 

[Chris Miller]

Well, that would find missing DLLs, perhaps, but if it's really about FontCharSet it must be about fonts and if there is a totally different object than you'd see from the recno as your project is out of sync with the EXE it's something else and you look at the wrong thing. That can happen fast, open a form once and saving can change recnos. VFP is packing SCX And VCX files.

It could also be something completely different like a missing ActiveX. Not missing on your dev machine, which explains why you see no error. Did you even look into the record numbers of the error messages? In the first message to verify it's the lblInterne object. In the second error, I don't know as you didn't show.

Error loading file should actually also tell which file (SCX or VCX). It's not necessarily the one with the method, that's likely just a do form in the C_INVOIC method and the problem is in the form it starts, not in the code with the c_INVOIC method.

And last not least, the error message (generic text individually differing in the n, the "object, the "Issue" and the "error":

Error loading file - record number n. "object" <or one of its members>. "Issue": "error".

That's error number 1881. So something goes wrong in your error handling, when you state it's error 2005.

Chriss

 

[Chris Miller]

I have to take back my last comment, reproducing the error I also do get error #2005.

One more idea: If you modify the Load event of forms to store SYS(16) somewhere into a txt file or DBF as "last started form" reference, an error handling of error 2005 cn inspect that form file (scx or vcx), go to the recno mentioned in the error number and store the property memo of that record to see what's stored in there right at the time it happens.

In form.load events (ideally in your baseform) put

StrToFile(Sys(16),"laststartedform.txt")

Either you keep it that simple, but have SAFETY set off, or you get tons of questions about overwriting. Better yet, change that to writing it into a DBF or append to a log file, or you store it into a PUBLIC variable. Whatever, also adapt the following error handling to find the last started form causing the error 2005:

In error handling handle 2005 errors this way:

AError(laError)

If laError[1]=2005
   lcRecno = StrExtract(laError[2],'record number ','.',1,1)
   lcLastForm = FileToStr("laststartedform.txt") && adapt according to where you store Sys(16) in form.load
   lcFormFile = StrExtract(lcLastForm,":\","SCT",1,4)
   lcForm = ForceExt(JustStem(lcFormFile),"scx")
   Use (lcForm) In 0 Again Alias problematicform
   Select problematicform
   Go Val(lcRecno)
   
   * adapt to store in an error.dbf, instead. Just for example:
   StrToFile("Properties of Record "+lcRecno+" in Form "+lcForm+":"+Chr(13)+Chr(10)+problematicform.Properties,"problematicpropertieserror2005[s][/s].txt")
EndIf

Then you can see what properties are actually loaded at runtime from the EXE. If there is no FontCharSet line in the properties (or whatever else is said to be illegal) then the default is illegal, which is unfortunate. In case of the FontCharSet the font name could also play a role. If that's also not set I think VFP stores a default font an size etc into the last record of an SCX and uses that, typically Arial. I think the label would then use that font or the OS tells the standard font the user configured in Windows settings. A missing font or a font not supported by VFP or GDI+ might cause this, too, in the end.

I strongly recommend you adopt this and don't use it 1:1 as in the form it is, you'll need write permission to the default folder, which could be the program files folder and then that's not working, also you would only ever save the last properties of the last 2005 error. I don't know what else you have in a base form class or whether you even use one, you also will need to embed this into your error handling as special case handling anyway. But that's enabling to see what properties are in play at the time of the error.

What this will not show in case there is no FontCharSet line in the properties, is what default value was causing that error. But perhaps the fontname will help to figure out whether there is a font missing or another problem with it.

Good luck with it.

Chriss