Is it possible to reimplement the IControlView interface for an EditBox control

[lyj2871]

Is it possible to reimplement the IControlView interface for an EditBox control in order to achieve a custom appearance for the EditBox?

My goal is to render text in different colors within a multi-line EditBox control.

To achieve this, I defined my own EditBox control like this:

type EVEMyMultilineTextEditBoxWidget(kViewRsrcType) : EVEMultilineTextEditBoxWidget(ClassID = kMyTextEditBoxWidgetBoss) { };

Class registration:

Class
{ 
	kMyTextEditBoxWidgetBoss,
	kTextEditBoxWidgetBoss,		
	{
	       IID_ICONTROLVIEW, 		kMyTextEditBoxViewImpl,
	       IID_IEVENTHANDLER,		kMyTextEditBoxEHImpl,
	       IID_MYEDITBOXPROXYVIEW,	kNudgeEditBoxViewImpl,
	}
},

 kNudgeEditBoxViewImpl is the default implementation of IID_ICONTROLVIEW for kTextEditBoxWidgetBoss.
Since the SDK does not expose the header files or base classes for some components,
a common workaround for reimplementing an interface without public base classes is to use delegation (or proxy),
as demonstrated in the SDK sample project PanelTreeView. For example:

class PnlTrvNodeEH : public CEventHandler
{
public:
	PnlTrvNodeEH(IPMUnknown* boss);
	virtual ~PnlTrvNodeEH(){}

	virtual bool16 Activate(IEvent* e) {
		bool16 retval;
		InterfacePtr<IEventHandler> delegate(this, IID_IPNLTRVSHADOWEVENTHANDLER);
		retval = delegate->Activate(e);
		return retval;
	}
	//... all other functions follow similar pattern
};

So in my custom kMyTextEditBoxWidgetBoss, I define a custom implementation for:

IID_ICONTROLVIEW, kMyTextEditBoxViewImpl

And I also include the default base implementation as:

IID_MYEDITBOXPROXYVIEW,	kNudgeEditBoxViewImpl

Below is part of the implementation of kMyTextEditBoxViewImpl. This is an experimental test.
I didn’t implement my own Draw() function yet.
Instead, I reimplemented all virtual functions of IControlView in the following way:
each method simply forwards the call to the corresponding method in kNudgeEditBoxViewImpl.

class MyTextEditBoxView : public DVControlView
{
	typedef DVControlView inherited;

public:
	MyTextEditBoxView (IPMUnknown* boss) : inherited(boss) {}
	virtual ~MyTextEditBoxView () {}

	virtual void Init(const WidgetID& widgetId = kDefaultWidgetId,
		const PMRect& fFrame = kZeroRect,
		RsrcID rsrcID = 0) 
	{
		InterfacePtr<IControlView> delegate(this, IID_MYEDITBOXPROXYVIEW);  
		delegate->Init(widgetId, fFrame, rsrcID);
	}

	virtual void DoPostCreate() {
		InterfacePtr<IControlView> delegate(this, IID_MYEDITBOXPROXYVIEW);
		delegate->DoPostCreate();
	}

	// ... all other functions follow similar pattern
};

CREATE_PERSIST_PMINTERFACE(MyTextEditBoxView, kMyTextEditBoxViewImpl)

However, after debugging, I noticed that none of the functions in kMyTextEditBoxViewImpl are actually being called,
except the constructor. Even Init() doesn’t seem to be invoked.

This made me wonder whether kNudgeEditBoxViewImpl actually implements IControlView or implements some other undocumented/private interface.

So I suspect that the line:

class MyTextEditBoxView : public DVControlView

may be incorrect, or that the issue lies elsewhere.

So, here are the questions I would like to have answered:

1. Is it possible, using the current SDK, to reimplement the EditBox appearance drawing?

2. If it is possible, should class MyTextEditBoxView : public DVControlView indeed inherit from DVControlView?

3. Is there a better way to achieve text in multiple colors inside a multi-line EditBox?

[Dirk Becker]

A long time ago, CControlView had platform specific versions MControlView and WControlView, where you could obtain the control's HWND (Windows) or TXNObject (Mac) via IControlView::GetSysControl(). You'd then use the platform's rich text editor calls such as ::TXNSetTypeAttributes() (Mac) to choose fonts, colors etc.

When CS changed to CC back with version 9, InDesign's widgets were also changed from directly wiring to native Carbon or Windows, to using an Adobe internal abstraction "Drover". With Drover the direct access was removed. I don't know whether Drover still uses the native controls. That's why I suggested you look yourself whether you can iterate the native Windows hierarchy.

Back then I gave up on native multiline editor widgets and wrote a replacement for the part that I needed, that is without editing. I'd recommend the same to you as it also gives full control for special characters, adornments (e.g. background of the tags) without fighting the differences between the OS/platform components later on. Below a screenshot from a preview for structured text that I used back in 2016 with a set of DAM connectivity plug-ins.

By going down that road, you can also directly use InDesign's typography. Hyphenation if is relevant to you, or all those OpenType features. You don't want to emulate them in an OS control and find differences when you place your contents. Here's an exercise in OpenType that predates the OpenType popup thingy.

Regarding colors, InDesign strictly differentiates between UI colors and those in layout, but then gets inconsistent with them itself. Here a recent set (CC 2024) of the UI color constants, together with the UI fonts (similar topic).

UI colors mean you get white text color on dark in "Dark UI" - and different dependent on UI color. On the other hand if you want closer to black-on-white, you'd follow the glyphs panel as I did above with the OpenType preview, or just stick to black-on-white?

Besides this is all deprecacted theory, because again since Drover Adobe uses a different UI color table, and they decided to withhold the headers from the SDK as with most of Drover, or at least sync the colors into the old lookup table for us plugin developers. Just have a look at a real tooltip background and how it is supposed to be.

You already mentioned attempts to get closer to the real colors, I've seen that other thread. How close though? Stick to the swatches panel? That includes gradients, tints, everything a rendering object (= swatch) has to offer. Or consider everything the various Output >> Preview panels have to offer? Never done either, therefor no answer.

Some more options:

Short from the layout view itself InDesign has no appropriate component, otherwise they'd have done better in the Interactive >> Notes panel.

You can wrap the editor widget in a custom drawn container/panel widget, where you overload the Draw(). E.g. overdraw the borders if they hurt your eyes. Won't help though with the background in DarkUI.

Another alternative: have a look at UXP. Close to web / html view so similar problems with typography and color matching, but at least you can specify colors with all flexibility CSS has to offer.

[lyj2871]

Thank you very much for your detailed explanation. My goal is to have a multi-line text editor that supports customizable colors—not just for display purposes, but also for actual text editing. I want it to automatically apply different colors to different parts of the text based on content.

As you mentioned, developing a fully custom native text editor control would require a huge amount of work, and the result might not integrate well with Adobe's built-in UI components. I'll start by exploring the solutions you suggested.