How to deliver with additional spelling dictionary?

OK, so far so good - it all works.

Now for the next quest. My app is branch specific, delivered with a huge text database. The purpose of including the OCX is to provide text editing within the app. This touches spelling in a certain way - the user may copy and paste a lot of text from the database into the editor, and I don't want that part of the text to have spelling errors. So I extracted all the words we have, and compiled a dictionary. And that works, well, on my development machine.

When it gets to delivering the installation CDs, how do I tell the spell checker to use both english.dct and my.dct without user intervention? Do I have to insert the values into the registry, or is there a set of wpa commands to do that? I haven't found any spelling-related wpa, so I better ask here.

Writing into registry works, like this:

lcSCPath="Software\WPCubed\WPSpell\SpellCheck-Files"
	GoApp.oRegistry.SetRegKey("DCT0",Realpath("english.dct"), lcSCPath, HKEY_CURRENT_USER, .T.)
	GoApp.oRegistry.SetRegKey("DCT1",Realpath("words.dct"), lcSCPath, HKEY_CURRENT_USER, .T.)
	GoApp.oRegistry.SetRegKey("DCTs",2, lcSCPath, HKEY_CURRENT_USER, .T.)
	GoApp.oRegistry.SetRegKey("DCTs.Disabled",0, lcSCPath, HKEY_CURRENT_USER, .T.)
	GoApp.oRegistry.SetRegKey("User",0, lcSCPath, HKEY_CURRENT_USER, .T.)

Now what's this RealPath() thing? It's where I instantiate a FileScripting object to get the file's full path name. VFP's FullPath() returns everything uppercase, and the spelling checker component just had to be case sensitive when reading the registry... !?

OK, solved, move on.

On some machines where I tested the install of my app, both dictionaries get registered OK. On some, none.

So... is there a sure-fire way to get the dictionaries registered during the installation (or at least at first run)?

Thanks - I'll be watching the forums. Just provide the syntax.

Zitat von wpsupport

Hi!

Something else ...

Normally you will use TextDynamic itself to print, but I now also made the OCX as such printable (it does not resize itself since there is no interface which controls this and stretching is of course impossible) - but on a standard MS Access Form this is a pretty nice feature. I don't know if this also works under Visual FoxPro - do you know if it also uses the IViewObject interface to print a control?

Probably doesn't, since I don't know what you're talking about :).

What do you mean by "print a control"?

As for resizing, I've put it in a container - and when the container resizes, I simply set the control's size equal to that of the container, and to the user it seems like it's resizing seamlessly just like any other control, so no problem there.

Actually, my customer decided we won't worry about where does the printing go. The end users of the app are extremely low-tech, as computer illiterate as can be. So... no worries :)

Zitat von wpsupport

Hi,

>> What do you mean by "print a control"?

I think I got my answer :-)

That's why I wrote it :).
Actually, "print a control" either makes no sense, or can mean any of
- printing a screenshot of it
- printing all of its properties
- getting its value into something that'd print

Since I'm the oddball here, I rather asked a stupid question than make a stupid assumption - what may it mean here :).

Zitat von wpsupport

In MS Access you can place text fields, images, labels and TextDynamic on your form (a virtual piece of paper) and with the upcoming release also TextDynamic will print into its bounding rectangle.

VFP form is where I'm hosting the TD OCX, along with just a few of my buttons (I've taken over the open/save/new because I need to handle the files myself).

So printing into its current form would be like a print preview?

BTW, for the next version, if possible: ctrl+B, ctrl+U and ctrl+I could run the bold, underline and italic toggles, just like they do in other editors. There may be people who are used to that. I tried catching that in OnKeyUp (or something with a similar name), but the shift parameter kept coming as zero, no matter which of ctrl+alt+shift I had pressed.

After two weeks of emails between Julian and me, we have a solution on how to access other interfaces in WPTDynInt (like .memo, .SpellCtrl etc).

It was Julian who found the VFP function GetInterface() (I'm ashamed - my last boss said I was among the top 100 VFP programmers in the world and I couldn't remember this function - there are only 445 of them).

In short, the solution:

somewhere in the code, best in .oTextDyn.Init

ospell=GETINTERFACE(this.SpellCtrl, "iwpspell", "WPTDynInt.ocx")ospell.AddFromFile(FULLPATH("words.dct"))ospell.AddFromFile(FULLPATH("english.dct"))

and that's it. Alternatively, the first line can be

ospell2=GETINTERFACE(this.SpellCtrl, "{8A8763C7-D866-4D33-A6E9-FF17C008D57B}", "WPTDynInt.ocx")

(Julian sent me the list of GUIDs)

There are other things that can be done this way. Using GetInterface(), I can access other things, like .memo etc, as needed. :wink: