Labview generated dll doesn't use appFont from .ini file.

[redfrank]

Hi,

I've written a dll in Labview 2014 and when I've come to port it from Windows 7 to XP the front panel displayed by the dll gets messed up.

This I have found to be due to the difference between default fonts in Windows 7 and XP. I've also discovered that setting appFont in the configuration file associated with a Labview generated .exe can fix this problem by forcing it to use the same font on both platforms. However, when I tried this out with my .dll, the appFont setting gets ignored. I tried setting the font on an executable using the same method, and this did work, so it appears to be an issue with the dll.

Note, I changed the Wait on debugger setting to true in the ini file to prove that the ini file was getting used, and the dll hung up, due to lack of a debugger, proving the ini file is getting used.

Has anyone else encountered this problem, and is there a fix?

Cheers,

redfrank

[RavensFan]

I'm confused.

I thought a dll is a library of executable code.  Are you saying that it also includes a front panel that gets displayed when it is used?

What does this .dll do, and how are you calling it?

[redfrank]

Yes, the dll is a library of executable code.

In this particular instance, when one of the dll functions is called it displays a Labview created front panel, which the user can interact with.

When the dll is created an .ini file with the same name is created by Labview at the same time.

This is the same as when an executuable is created.

However, when I set appFont="Tahoma" 20 in the dll ini and run an executable which calls functions within the dll, the font setting is ignored, whereas when I do the same in an executable generated from Labview, the font size is reflected in the front panel when the .exe is run.

I've just created a very simple vi which multiplies 2 numbers to an an indicator. If I generate an executable from the vi, the appFont setting in the ini file is reflected.

If I generate a dll containing 1 function from this vi, and run it using rundll32, it ignores that font setting.

[RavensFan]

Instead of defining fonts within the dll's VI's as appfont, systemfont, or anything else where it draws from the OS as to what font to actually display, define those fonts as "hard" fonts.  Define the label of a control as "Tahoma 10" instead of as AppFont and hoping that a system setting or .ini file setting manages to find its way into that subVI.

[redfrank]

Yes, I was thinking I may have to do that - although what I'm doing should work, no?

Are you saying that this feature doesn't work the way it should for dlls?

It seem strange that the ini file is used by the dll for certain settings...

I was wondering if something about the calling exe overrode the font settings?

[redfrank]

Ok, this problem hasn't gone away, and I've just discovered an additional issue that affects the functionality of the dll generated, not just the comestics.

The front panel I display contains a series of tables which the user enters test data into and the code then checks these test values against limits specified in another part of the table. I've discovered the NumRows property of a table doesn't return the number of rows containing data, as I'd assumed, but the number of rows visible on the front panel.

When the dll is run from Windows 7 with the default theme, the last row of the table isn't displayed due to the increase in font size. This means this last test isn't getting done and a potentially faulty unit could be delivered.

If I change the theme to Windows classic, this problem is resolved, but if the user decideds on a whim to change the Windows desktop theme, the end result is it changes the functionality of my code!!!!

Why doesn't the .ini file use the font settings specified????

[RavensFan]

I have no idea how things should work for .dll's as I've never created nor do I think I'll ever need to create a .dll in LabVIEW.  My guess is that LabVIEW development environment knows to get those font settings from LabVIEW.ini.  A LabVIEW built executable knows to get the settings from the exectuable's .ini that is saved in the same directory as the .exe.  But .dll's don't have a corresponding .ini to look at.

As for NumRows, yes it is for number of visible rows.  If you want to know the number of rows that has data within a table, you just need to use the array size functions on the table.

I don't know why a test would not be done because that row of a table is not visible.  Your program should be written to handle everything that is in the array, not just what happens to show on a front panel.

[redfrank]

The thing is the dll does have a corresponding .ini file associated with it.

The .ini file I'm modifying is generated by the build process that generates the dll, just as an .ini file is created along with an .exe.

As I've already mentioned in my post, I've proved the dll is using this .ini file as it uses the debug flag from this file.

If you don't know the answer that's fine, you don't need to guess... 😉