TextControl ActiveX X15 and VFP 1

[atlopes]

Dear All

I've been working with VFP & TextControl (from

https://www.textcontrol.com)

since the 20th century, from a-I-can't-recall-exactly-which early version up to TextControl 14, and, on the VFP's side, from VFP6 to VFP9.

Recently, an opportunity to upgrade the component to the most recent version, X15, came into consideration, and I decided to test and see if it integrates well. As distributed, the trial version is incompatible with VFP, because of a trial mechanism embedded in the component deployment, but the good people of TextControl offered me a 30-day unlimited package for me to try, and with that, the licensed class was, at least, recognized.

Two problems, now:

a) although registered, the OCX for the X15 version does not appear in the ActiveX list of controls that can be dropped in a form. I can drop a TextControl 14, but the X15 is not in sight.

b) I can add the X15 control at runtime, but an "Unexpected Text Control error 1-e00" pops up at the signaled line. The control is inserted, nevertheless, and it's usable (it responds to the properties changes, for instance, and the content can be edited).

LOCAL Test AS TxcForm

m.Test = CREATEOBJECT("TxcForm")
m.Test.Show(1)
m.Test = .NULL.

DEFINE CLASS TxcForm AS Form

	WindowType = 1
 
	PROCEDURE GotFocus

		[highlight #FCE94F]This.AddObject("TXC", "OleControl", "TIS.TX.TextControl.25")[/highlight]

		WITH This.TXC
			.Width = This.Width
			.Height = This.Height
			.EditMode = 0
			.ViewMode = 2
			.Visible = .T.
			* just to report the inserted OLE control
			MESSAGEBOX(This.TXC.OLEClass)
		ENDWITH

	ENDPROC

	PROCEDURE Resize
		WITH This.TXC
			.Width = This.Width
			.Height = This.Height
		ENDWITH
	ENDPROC

ENDDEFINE

Does anyone have experience with VFP & recent versions of TextControl integration that could share, and explain what am I doing wrong, or not doing yet, to make things work? Or, eventually, have any advice on something for me to try.

Thanks in advance

António

EDIT: the thread subject and this first post was corrected to refer to the actual name of the current TextControl version, X15 (even if the ProgID uses a different sequence, and indicates 25).

 

[Olaf Doschke]

Using any OLE Control, especially visual ones, the first step I do is make an Olecontrol based class being the "host" of the control.
It's intended for that usage. Just Olecontrol, not Oleboundcontrol.

Try and see if that removes the error.

Bye, Olaf.

 

[atlopes]

Thank you for your insight, Olaf. Unfortunately, the behavior does not change when I subclass an OleControl.

Is this what you meant, right?

DEFINE CLASS txcControl AS OleControl

	OleClass = "TIS.TX.TextControl.25"

	EditMode = 0
	ViewMode = 2

ENDDEFINE

I forgot to mention that when I use the version 14's ProgID, that is, "TIS.TX.TextControl.14", everything runs fine (no error message at the instantiation). Of course, that version is also available for me to visually drop it on a container.

 

[Olaf Doschke]

Yes, that's what I meant, rather as visual control, but shouldn't matter.

It was worth a try. Does it work dropping it visually on a form at design time instead of Addobject at runtime?

Bye, Olaf.

 

[Nigel Gomm]

insert the olecontrol onto your container/form and, if the control is not listed in the insert object dialogue, try changing the radio button to 'create from file' and browse to the ocx.

hth

n

 

[StefanFoerner]

Hi António,

on a few forms I am using the Microsoft Web Browser control.

Instantiating the form and the control the following error is thrown:

1426: OLE-Fehlercode 0x80004005: Unexpected error.

After searching for hours and days to find the reason, no solution in sight, but:

I put the following code in the error event of the form:

IF nError != 1426
	windowsError( ERROR(), MESSAGE(), PROGRAM(), LINENO(), MESSAGE( 1 ), LINENO( 1 ) )	&& own error handler
ENDIF

Now no error and everything works ...

Regards, Stefan

 

[atlopes]

Thank you all, Olaf, Nigel, and Stefan.

I think I managed to advance on this.

Although the X25 version continues to not appear in the list of ActiveX controls to drop into a container, it is visible in the list of available controls that can be inserted in the ActiveX toolbar (could it be because the 2 versions share the same name, "TX - Text Control"?). I inserted the set of TextControl controls - text editor, button bar, ruler and status bar - in the toolbox, and now they can be visually dropped anywhere.

I put a simple editor just to check that the controls are working ok, and operating as they should:

With visual dropping, the initial error disappeared. I'll continue to evaluate this version of the control further on, but so far it seems to going fine. I hope this won't get reverted.

Nevertheless, I will be completely satisfied only when I get to add a Text Control object into a form in runtime, which is required for VFP modal forms (and as the version 14 allows). Trapping the error specifically, as Stefan suggested, may be eventually the only solution, but perhaps the TextControl people may want to have a look at it.

Once again, thank you all.

António

 

[atlopes]

A final correction: although the TextControl ProgID version indicates 25, the official name of the version is X15. Sorry for any misunderstanding that this may have caused.

 

[Olaf Doschke]

Well, the Insert Object dialog shows different versions of controls, at least if they have different names:

You might try "Add Control" and navigate to the OCX file.

But to put your OCXes into the toolbox is even better anyway, that allows more direct access to it, with a list you manage yourself.

add ... in runtime ... which is required for VFP modal forms

Why?

Bye, Olaf.

 

[atlopes]

You might try "Add Control" and navigate to the OCX file.

That was one of the walls I banged my head on before starting this thread, but got this quite unhelpful message box in return.

Probably, something related to this one, which is the error I get when adding the control in runtime.

Quote (atlopes)
add ... in runtime ... which is required for VFP modal forms

Why?

Guess work: I think it is a focus issue. The TextControl claims and receives the focus for its hWnd, and the VFP form does not even get to be fully shown. Even in design time, MODIFY a FORM with a TextControl on it sets the focus on the control, not on the form as usual.

As it happens in the first code of this thread, the control must be added after the Show event of the form (that is, in form's GotFocus of Activate events). Otherwise, the form just vanishes in thin air, although being modal.

 

[Olaf Doschke]

You might take a look at this in regard of VFP modal forms and ActiveX:

http://www.foxpert.com/foxpro/knowlbits/files/knowlbits_200801_1.htm

Bye, Olaf.

 

[atlopes]

That's a very insightful article, thank you for pointing me to it, Olaf.

The problem I'm facing it's a bit different, though. It's about how to add this particular ActiveX control to a modal form.

As far as I figured it out, the only way to use a (subclassed or not) TextControl control to a VFP modal form is to add it at runtime, and this has been working nicely with the previous version of the control that I'm using in production.

 

[Olaf Doschke]

Yes, but the article hints on what might be working and hindering the error, if you add the control at designtime and handle it with the API calls in the form activate.
Have you tried that, or did you stop reading because it mentioned design time usage of controls?

Bye, Olaf.

 

[atlopes]

I didn't stop reading till the end ;-)

I even tried to enable all the windows involved (the VFP host and the TextControl's) in the Activate event. It does not make a difference.

What really makes a difference <blush reason="selfShame">is to put a single / simple

This.Visible = .T.

in the Activate event. With this now I have a full modal VFP form capable of hosting a TextControl control at design time.</blush>

Thank you for the interest, Olaf. It has been priceless, as always.

 

[Olaf Doschke]

No need to blush, because nobody could foresee that delaying visibility of a control already helps getting it to work.

The most know quirk perhaps is the need to override the Webbrowser Control Refresh(), but the reasoning also isn't very straight forward. But in the end it's a simple solution, if you know it. Simple to apply, but aks anyone, why this solves what problem...

It's fine that you post the solution here, very well appreciated, because it's as simple, yet as "mysterious". In some aspects it's really a relief to not only need to work in VFP anymore, with such and many more quirks of which major parts of VFP experts knowlegde consists of.

Bye, Olaf.

 

[Olaf Doschke]

If you look further at foxpert or perhaps also in Universal thread in posts of Christof, I think he even showed a way to circumvent the inability of changing WindowType from modal to modeless and back at runtime by doing this while hiding the form. So the readonly state of the WindowType property at runtime becomes writable. I don't know the exact circumstances, but your solution with the visible state of the ActiveX reminds me of that.

Bye, Olaf.

 

[atlopes]

Thanks again, Olaf, I'll search for Christof's articles.

To sum up what is most relevant to this thread:

a) Having more than one version of TextControl installed in a machine makes hard to drop the control visually into a container, probably because the name of the control is not versioned, and the list that VFP builds disregards the reference to the control with a repeated name. The solution is to insert the control in a toolbar, or toolbox, because the list that is formed to select a control presents all available ActiveX objects, having their names repeated or not.

b) To use a TextControl control in a VFP modal form, one must set the Visible property to .T. after it is shown (in the form's Activate event, for instance).

Both workarounds may apply to the integration of other controls in similar circumstances.

c) Instantiating the TextControl control programmatically raises unhelpful error messages. Hopefully, TextControl people will have a look at that.