[RESOLVED] About MSSTDFMT.dll

[Daniel Duta]

Hi,
I have an application that until now worked without any dependency of this library but today I have noted that each time my app does create a reference to it even I don't remember if I called any new function or library from outside. Does anyone know how this Microsoft Standard Data Formatting Object Library is related to those native vb controls ? As I know this library is missing from Windows 7 and I was able to install many VB6 executable files in Windows 7 without any reference to that library and they worked properly. Do you have any experience /explanation regarding this issue ?
Thank you.

[dilettante]

The msstdfmt.dll is used by quite a number of OCXs that ship with VB6. There was never a version of Windows that shipped with this DLL preinstalled. Normally it would include any OCX that uses it, i.e. those that support a DataFormat or similarly named property either at the top level or somewhere within their object model.

Even certain ADO objects such as Field can make use of this DLL via the Properties dynamic properties collection.

These are late-bound though so if you don't make use of them your program wil never try to load msstdfmt.dll just because you use ADO or a control.

As far as I can determine Windows 7 doesn't ship with any OCX that has msstdfmt.dll as a dependecy anyway. So you'll need to package everything you need in order to deploy to Windows 7 anyway, and thus there shouldn't be a problem. If you are only using intrinsic controls then just avoid using the data binding properties including DataFormat.

As it says in the documentation provided with VB6:

The Microsoft Standard Data Formatting Object Library is required for controls that implement a DataFormat property. An Application Error occurs when a control makes an attempt to use the DataFormat property and the Microsoft Standard Data Formatting Object Library is not registered. Controls that implement a DataFormat property include, but are not limited to, the following:

CheckBox, ComboBox, Image, Label, ListBox, PictureBox, TextBox, ImageCombo, MonthView, DTPicker, Calendar, DataCombo, DataList, DBCombo, DBList, MaskEdBox, RichTextBox.

[Daniel Duta]

Hi Dile,
Thank you very much for your documented reply. It is first time when I experienced something like this and it was difficult to search through all application controls (over 40) to find that minor but annoying dependency. Finally i found that a simple TextBox had the DataFormat property set as numeric and it is strange that I couldn't set it as before (blank box) without to remove the TextBox itself... After I reinserted the TextBox in the form, with DataFormat property as blank (default) the reference to that msstdfmt.dll disappeared. Imagine, a simple call of a (not very useful) property could involve a link to other library so that to be constrained to package it too.
I wonder if there is any possibility to read all functions, properties embedded in a dll.
Or, in my case, how could I determine all links/dependencies among my controls and other libraries outside of my application ? Thank you.

[dilettante]

If you have installed the Visual Studio Tools with VB6 you should find the Depends.exe tool. This may give you more detail than you expected though.

[Daniel Duta]

In my Microsoft Visual Basic 6.0 Tools I have only API Text Viewer and Package Wizard. Nothing related to that Depends.exe. But it is true, my VB6 is not installed via Visual Studio package. Anyway using the Dependency Walker instead I didn't find any dependency of msstdfmt.dll. Have you managed to find this dependency with Depends.exe ? Maybe the msstdfmt.dll is called from other libraries and that relationship is less visible.

[LaVolpe]

I know this is resolved, but curious if you simply added that library to your project references, even though it may not have been invoked in the project, whether the library would've been included in your setup package?

This doesn't solve the problem of knowing which libraries are needed based on whether or not some control property is set or not. But this thread was useful nonetheless for others that may be using the DataFormat properties of controls and want to ensure that library is included in their setup packages

[dilettante]

If you happen to set the DataFormat property of an intrinsic control at design time the IDE will add the reference to the project for you. OCXs should have an associated .DEP file listing this library as a dependency if it is required.

This should be enough for most VB-friendly packaging tools such as the PDW, VSI 1.1's VB Wizard, or MMM to add it to their dependencies lists. All bets are off if you don't use a packager that scans .VBP and .DEP files.

Be sure you are using a legal and properly installed copy of VB6 and the related tools so that you can install VB6 SP6. The PDW had a lot of small things fixed over the years. The so-called "Portable Edition" is a pirated copy of VB6.


Depends.exe is Dependency Walker. I was able to see that msstdfmt.dll is loaded, but since it is dynamically loaded you have to profile the EXE to see that:

[dilettante]

I know this is resolved, but curious if you simply added that library to your project references, even though it may not have been invoked in the project, whether the library would've been included in your setup package?

While there is a Project setting to Remove Unused Control Information, I think it only applies to OCXs (i.e. DLLs added through the Components dialog, not the References dialog, OCX just being another extension for a DLL of course - one use for control libraries by convention).

So if you manually add a Reference to msstdfmt.dll it will be left in the .VBP file, and the PDW will list it as a dependency to be packaged unless you "uncheck" it from the list of items to package.

[Daniel Duta]

If you happen to set the DataFormat property of an intrinsic control at design time the IDE will add the reference to the project for you.

It is exactly what I have done. I have set the DataFormat property of a TextBox at design time and the IDE added each time a reference automatically (phenomenon that is easy to check). For this mistake (option) I had to package the msstdfmt.dll because I didn't have enough time to search/understand what settings created that dependency overnight.

Depends.exe is Dependency Walker. I was able to see that msstdfmt.dll is loaded, but since it is dynamically loaded you have to profile the EXE to see that.

I didn't know (until now) that Dependency Walker was part of the Visual Studio 6.0 especially as it was developed by a guy Steve Miller on 2006 (but, yes, with MS copyrights). I re-run the DW tool in profile mode and I was also able to find that dependency. Thank you for the hint.

if you simply added that library to your project references, even though it may not have been invoked in the project, whether the library would've been included in your setup package?

I have not tested this scenario using an installer (I don't think is any difference) but making a simple exe file with a reference to msstdfmt.dll the file could be opened without any error - as long as the DataFormat property was not set but once it is set (at design time) the following error occurs : "Class not registered. You need the following file to be installed on your machine : MSSTDFMT.DLL".
So the error arises only if that property is invoked at design time. And, yes, I confirm I compiled the file having checked the option "Remove information about unused ActiveX Controls".
Thank you for your interest in my issue.