DefOLELcID, OLELcID

These two properties were added in the 3.0b revision of Visual FoxPro to support multilingual applications. Along with SYS(3004) and SYS(3005), they determine the locale ID used for the user interface of OLE Controls sensitive to this property.

Usage

frmForm.DefOLELcID = nLocale
nLocale = frmForm.DefOLELcID
nLocale  = oleControl.OLELcID

Parameter	Value	Meaning
nLocale	0	Use the default OLE Locale ID of the form, or the system default determined with SYS(3004).
nLocale	Other	See the documentation for SYS(3005) for a partial list of acceptable values, or the Windows SDK documentation for more thorough coverage.

The DefOLELcID and OLELcID properties affect the language used for the user interface of OLE controls; the OLE Automation commands are unaffected (use SYS(3005) to change the OLE Automation commands). DefOLELcID properties apply to a form or the main Visual FoxPro _SCREEN. This property can be set or read. The read-only OLELcID property can be queried for individual controls.We think Microsoft went out of its way to make this property hard to decipher—why didn't they take out all the vowels while they were at it? "DefaultOLELocale" would not have been that much longer, and far easier to comprehend. We suspect it was one of those other languages, or perhaps the OLE team itself, that created this funky term, and the Fox team was just forced to go along with the joke.

Example

* Set a form's DefOLELcID to 1036 (French) or 1031 (German).
* Add an Outline OCX to the form.
* Right-click on the OCX and select 'Properties...'
* Note the 'General' tab is labeled 'G�n�ral' or 'Allgemein'
* Note, too, that everything else here is in English!
 
* In an international app, store the language properties
* in a global application status property, and set the
* language of each form on startup.
Procedure Form.Load
thisform.DefOLELcID = oApp.GlobalSets.DefOLELcID

Changing a form's DefOLELcID doesn't change the display in the property window for any of the OLELcIDs. Hacking the SCX reveals that this "property" is never even stored for the OCX, but just reflects the setting of the form. Our theory is that this isn't truly a property of controls at all, but only the form's property exposed at this level at runtime. This is contrary to the Help file, but probably makes more sense—how many times do you want a form where each OLE control speaks a different dialect?