swell text entry

[olilarkin]

hi,

i am trying to create a cross platform text entry control for IPlug, but i can't figure it out. I just want something like the bpm entry box in reaper. Can anyone suggest how i can do this with swell?

thanks,

oli

[cerberus]

i have requested that this function, (which is present in many osx vst and also a.u.) be activated
since i purchased bpmbadier from stillwell. i feel this issue represents a dysfunction in the osx
versions; a documented feature is absent. otherwise i feel very comfortable with the way iplug-based
plug-ins work from the standpoint of an end user.

but it appears that the vst compile has been crippled by disabling direct text entry
in order to please apple, or logic users (a.u. problems i wish to remain apart from).
that does tend to discourage me from buying more plug-ins that use iplug.

[junioreq]

Did you look at the ISpinnerControl control done up by CC? I haven't quite figured it out either..

~Rob.

[olilarkin]

actually i had forgotten about ccs controls, i borrowed some code from there and now i have it working (cocoa only so far)

oli

[Justin]

Hmm it would be pretty easy to add this when targeting Cocoa, but honestly my Carbon is weak enough that I'm not sure the best way to target Carbon. I'll see if I can prod schwa to add Cocoa text entry support (it should be easy for him, I'd imagine).

[cc_]

The code in my IPlug mods should allow text editing of controls in Cocoa and Carbon (both composited and noncomposited now). The ISpinnerControl lets people click to edit the value, but also gives the option of changing the value by dragging like a knob.

I haven't updated for the latest wdl yet, but the patch seemed to apply cleanly:

http://forum.cockos.com/showthread.php?t=52820

[olilarkin]

thanks cc, i have implemented the carbon code now based on yours, but i noticed some problems, like the control not getting focus automatically, however i'm not sure if i missed something when i was copying your code.

incidentally how do you apply the .patch file?

oli

[cc_]

Which host did you have the carbon problems in?

The patch is easy to apply (on a Mac or anything else Unix based at least), just cd into your wdl directory and then type something like:


patch -p1 < PATCH_FILE


I'm sure there are windows binaries for patch somewhere too, but I've never had to use them.

[olilarkin]

i have some crashes with my version in cubase... got to investigate. With yours i have noticed a couple of problems in Cubase and Live, see this video

1 - the control doesn't get focus initially
2 - the mouse cursor goes awol (as if masked by controls)
3 - keys get sent to the host e.g. when i press enter it starts playback in cubase

Carbon is horrible!

[cerberus]

Hmm it would be pretty easy to add this when targeting Cocoa, but honestly my Carbon is weak enough that I'm not sure the best way to target Carbon. I'll see if I can prod schwa to add Cocoa text entry support (it should be easy for him, I'd imagine).

ty justin!

[cerberus]

that does tend to discourage me from buying more plug-ins that use iplug.

but it didn't discourage me from attempting to build my own plug-in with iplug. :)

i've worked around this issue in my design, but i find that i cannot display formatted
text using "IText". the "color" parameter is the only formatting option that i can
get working so far. the same code i am using is reportedly working with windows.

[schwa]

but it appears that the vst compile has been crippled by disabling direct text entry in order to please apple

This is probably clear, but just for context, the issue is that iplug just doesn't have support for putting up a Cocoa or Carbon text entry field. There's no issue about disabling something, it's a feature that hasn't ever existed.

Similarly, the text display features are limited on Windows and extremely limited on Mac. LICE's text display features are pretty good now (they didn't exist when iplug was written), so the "right" thing to do is to implement text drawing in iplug using LICE_CachedFont. This isn't a quick job, though.

[cerberus]

thank you schwa; i'll probably need help on implemeting LICE_CachedFont.
since i downloaded wdl on july 19; the same day i started learning c++;

but now i have my first plug-in almost completed. i'll find some way to
make it appear like it is working to the end user (just me, so far...
and i wouldn't trust a plug-in from someone who started learning
c++ only last week. lol). so it's not finished yet, almost though.

http://gyazo.com/d94150bc18f2d9d9b543c12969581e76.png
"my first IBitmapOverlayControl" in action

[Tale]

Carbon is horrible!
I couldn't agree more. Last Friday I thought I'd give the Carbon text entry a go. It worked, kind of, and I even managed to make it auto focus. However, then I found a new issue: If you press Enter to confirm your entry, and the text is selected, then all text is replaced with a space. If the text isn't selected, then pressing Enter will add an extra space to your text. This is fixable, but who knows what is next.

So for now I've given up on Carbon. I'd rather have no text input than a crashing plug-in.

[olilarkin]

I eventually got it working by studying how it's done in vstgui. There are still a couple of issues (for instance if you click the text to make an edit box and then highlight another window, the box should disappear but it doesn't), but no crashing.

i've attached all my IGraphics code, hopefully you can find the bits i have modified by searching for the text OL_ADDITION

thanks to CC, whose code i used for the cocoa version

oli

EDIT -> i forgot one major remaining issue... in the carbon version my controls don't redraw after pressing enter

[Tale]

Thanks, I will check it out. :)

EDIT -> i forgot one major remaining issue... in the carbon version my controls don't redraw after pressing enter
I think this line from cc_'s version may solve this issue:

if (!mIsComposited) UpdateControls(mWindow, 0);

I don't know what happens if mIsComposited is true though.

[Tale]

There are still a couple of issues (for instance if you click the text to make an edit box and then highlight another window, the box should disappear but it doesn't), but no crashing.
I quickly browsed through your code just now, and it looks very promising. Unfortunately I have left my MacBook at home, so I can't try it at the moment.

About the box not disappearing when highlighting another window: Is the the kEventClassWindow > kEventWindowDeactivated in IGraphicsCarbon::CarbonEventsTextControlProc() ever executed? I kinda would expect it to work if you would move kEventClassWindow > kEventWindowDeactivated into IGraphicsCarbon::CarbonEventHandler(). But this is just me thinking aloud, I have no idea if this will actually work or just mess things up.

[olilarkin]

About the box not disappearing when highlighting another window: Is the the kEventClassWindow > kEventWindowDeactivated in IGraphicsCarbon::CarbonEventsTextControlProc() ever executed? I kinda would expect it to work if you would move kEventClassWindow > kEventWindowDeactivated into IGraphicsCarbon::CarbonEventHandler(). But this is just me thinking aloud, I have no idea if this will actually work or just mess things up.

this seems to work -thanks

if (!mIsComposited) UpdateControls(mWindow, 0);

this doesn't unfortunately

[Tale]

How about this then:

mGraphicsMac->SetAllControlsDirty();

?

[olilarkin]

turns out the only area that was getting redrawn was where the text editing box was located. I managed to fix that by adding this in EndUserEdit()... now to try and understand why it worked

IRECT r;

if (mGraphicsMac->IsDirty(&r)) {
if (mIsComposited) {
HIViewSetNeedsDisplayInRect(mView, &CGRectMake(r.L, r.T, r.W(), r.H()), true);
}
else {
int h = mGraphicsMac->Height();
SetRectRgn(mRgn, r.L, h - r.B, r.R, h - r.T);
UpdateControls(mWindow, 0);// _this->mRgn);
}
}

[Tale]

I think that for your host mIsComposited is true, so

HIViewSetNeedsDisplayInRect(mView, &CGRectMake(r.L, r.T, r.W(), r.H()), true);

is executed, which updates the rectangle containing all controls.

I suggested to make all controls dirty, because I think this will make CarbonTimerHandler() to execute exactly the code you posted, but without having to copy the code into EndUserEdit().

[olilarkin]

i tried that but it didn't work

[Tale]

I think I have everything working now in Ugly VSTi (http://www.refusesoftware.com/products/feature/3), a free Carbon VSTi host. Ugly VSTi is a non-composited host I guess (because mComposited is false). Does anyone know any free composited Carbon VSTi host which I can use to test things in?

BTW, I am now calling both SetDirty(false) and Redraw() right after SetValueFromUserInput(), so the control will always get redrawn, even when its value hasn't changed.

[olilarkin]

try the demo of ableton live?

[Tale]

Yes, thanks! The Ableton Live indeed uses composited Carbon for VSTs.

[Tale]

Ok, I think I have found it. There appears to be a bug with drawing composited views in IGraphicsCarbon::CarbonEventHandler > kEventClassControl > kEventControlDraw. Take a look at this code snippet:

int gfxW = pGraphicsMac->Width(), gfxH = pGraphicsMac->Height();
IRECT r = GetRegionRect(pEvent, gfxW, gfxH);
...
if (_this->mIsComposited) {
...
pGraphicsMac->Draw(&r);
}
else {
...
// Old-style controls drawing, ask the plugin what's dirty rather than relying on the OS.
r.R = r.T = r.R = r.B = 0;
_this->mGraphicsMac->IsDirty(&r);
}

pGraphicsMac->Draw(&r);

So for composited views IsDirty(&r) is never called, which is why it won't redraw the entire control. Also, Draw(&r) is called twice (?). This is not a problem, but it is probably unnecessary.

Here is the changed code which fixes things in Live (but I haven't tested it elsewhere yet):

int gfxW = pGraphicsMac->Width(), gfxH = pGraphicsMac->Height();
IRECT r = GetRegionRect(pEvent, gfxW, gfxH);
...
if (_this->mIsComposited) {
...
//pGraphicsMac->Draw(&r);
}
else {
...
// Old-style controls drawing, ask the plugin what's dirty rather than relying on the OS.
//r.R = r.T = r.R = r.B = 0;
//_this->mGraphicsMac->IsDirty(&r);
}

// Old-style controls drawing, ask the plugin what's dirty rather than relying on the OS.
r.R = r.T = r.R = r.B = 0;
pGraphicsMac->IsDirty(&r);
pGraphicsMac->Draw(&r);

[Tale]

There appears to be a bug with drawing composited views in IGraphicsCarbon::CarbonEventHandler > kEventClassControl > kEventControlDraw.
Well, perhaps this is not a bug. If you don't apply the fix in my previous post, but instead do this, everything also seems to work:

if (_this->mIsComposited)
{
IRECT* pR = _this->mEdControl->GetRECT();
HIViewSetNeedsDisplayInRect(_this->mView, &CGRectMake(pR->L, pR->T, pR->W(), pR->H()), true);
}
else
{
_this->mEdControl->SetDirty(false);
_this->mEdControl->Redraw();
}

[sstillwell]

i have requested that this function, (which is present in many osx vst and also a.u.) be activated
since i purchased bpmbadier from stillwell. i feel this issue represents a dysfunction in the osx
versions; a documented feature is absent. otherwise i feel very comfortable with the way iplug-based
plug-ins work from the standpoint of an end user.

but it appears that the vst compile has been crippled by disabling direct text entry
in order to please apple, or logic users (a.u. problems i wish to remain apart from).
that does tend to discourage me from buying more plug-ins that use iplug.

FWIW, if IPlug supports it, so will I.

Scott

[Tale]

I guess eventually direct text entry for Mac will make it into the official IPlug distribution.

Meanwhile, I am more or less ready and happy with my own modifications. Here is what I now have:

Windows: Text input and combo box; while text entry is active controls can still be edited using mouse; auto focus.
Cocoa: Text input and combo box; while text entry is active other controls can still be edited using mouse; auto focus.
Carbon: Text input (no combo box, enums are treated as ints); while text entry is active controls can't be edited using mouse; auto focus.

Not 100% consistent, but good enough for me (for now anyway).

I case anyone would like to test things: I have just uploaded a new beta version (http://www.martinic.com/combov/downloads/) (v1.0.3 beta2) of ComboV, which uses these modifications. The source code for my modifications can be downloaded here (http://www.taletn.com/wdl/tale_iplug_contribs.zip).

[cerberus]

FWIW, if IPlug supports it, so will I.

hey scott, there are a few mods/patches floating around here.
perhaps a solid method to enable itext entry/selection for (at
least cocoa-based hosts like reaper) already exists ? if you
would build a bombadier using tale's mods, for example, i
would be happy to test it. i am tempted to test these mods
with the plug-in i am developing atm.

[sstillwell]

I'll have to take directly from the IPlug distribution where I know what the license terms are...grabbing someone else's individual patch that hasn't been accepted into the distribution can have legal/licensing repercussions that I don't want to deal with.

Otherwise, yeah, I suppose it's possible.

Scott

[cerberus]

well i got something working... i didn't really understand that caption control
is taking over all IText, except for color... well i won't need direct text
entry in my plug-in, if my dastardly plan works as i imagine it should.

i would like that itext to be selectable for copy-paste, then again i
don't want any legal problems.

and does anyone know why my dB text display
is being rounded or floored to six digits?

http://gyazo.com/dc85db5ba7bd69c93f459c7d5bc707a1.png

[Tale]

and does anyone know why my dB text display
is being rounded or floored to six digits?
Probably because you are using sprintf() without specifying the number of digits, and the default for a floating point number (%f) is 6 digits. I.e.:

sprintf(str, "%f", db); // Defaults to 6 digits
sprintf(str, "%0.12f", db); // 12 digits

[cerberus]

that does work. ty tale!

[cc_]

Hey, great work oli and tale! I took a break worried that I'd have to come back and fix all that carbon stuff, and I get back a find it's all done!

Is there any chance someone (tale?) could post up their current versions of IGraphicsCocoa.* IGraphicsCarbon.* and IGraphicsMac.* - I downloaded tale's zip file, but I'd rather have the whole files so I can use diff and patch.

[Tale]

Your wish is my command! :) I have updated my tale_iplug_contribs.zip (http://www.taletn.com/wdl/) file, so it now also contains the IPlug source files after applying my bugfixes and mods.

[cc_]

Thank, that should keep me busy for a while!

[cc_]

I meant thanks of course, certainly more than one thank was needed!

I really wanted to dump my code and use the tale/oli instead, but there were a bunch of things that mine did that theirs didn't. So instead I used the code to fix the problems in mine, I didn't see any crashes, but there were problems with focus that oli mentioned above and also things not redrawing right.

I've tried it on OSX10.5.8 with Cubase 4.5, Reaper 3, GarageBand and Live 7 both AU and VST and it now looks OK to me. If anyone else wants to give it a go, I compiled my modded IPlugExample and put it here (both VST and AU): text_edit_test.zip (http://burbleland.com/tmp/text_edit_test.zip).

Any feedback would be appreciated.

I'll post up my updated code soonish... I need to get onto the latest wdl.

BTW I noticed that neither the oli nor tale version had my fixes for the mouse right button in them. Have you guys tried your code with a two button mouse? Does it work right clicking to open the edit box? When I tried it I don't think it did, but I have a macmini with a logitec mouse plugged in so maybe that's different from the apple ones?

Also oli's code has the " [super mouseDown: pEvent];" line in still, see: http://forum.cockos.com/showthread.php?t=58086 .

Hmm, I've probably forgotten more stuff...

[cerberus]

http://gyazo.com/94811e52fae290e13925688b889af8fd.png
http://gyazo.com/51b075613ae78dff2f056ed05f6adfe5.png

activated by right-click... all seems working. nice work cc_ !

[cc_]

Thanks for trying it! But don't get too excited, Reaper VST is the easy one, it's all the others where the problems show up...

[RRokkenAudio]

Heh, don't even bother with XT lol...

~RR.

[Tale]

I've tried it on OSX10.5.8 with Cubase 4.5, Reaper 3, GarageBand and Live 7 both AU and VST and it now looks OK to me. If anyone else wants to give it a go, I compiled my modded IPlugExample and put it here (both VST and AU): text_edit_test.zip (http://burbleland.com/tmp/text_edit_test.zip).
I have tried your text edit test in various hosts on OS X 10.6.4, and here are the results:

REAPER (v3.66; OSX Intel)

Everything works. I did find two nitpicks:

[AU/VST] Hoover the mouse over the small +/- buttons for the pan knob, scroll up using the mouse wheel, and the small button will appear to be pressed. You can fix this by adding an empty OnMouseWheel() method to your control.
[AU/VST] A control that is being editing using the keyboard also still reacts to the mouse wheel, but this doesn't update the value in the input box. On Window the value is updated, but I found this too much of a hassle on Cocoa. So I have chosen to temporarily disable the mouse wheel for the control that is being edited.

Ableton Live Intro (v8.1.4)

Again everything works, but there are a few additional nitpicks:

[AU] When the plug's window isn't the active window, the input box doesn't automatically receive focus. You can fix this by calling the makeKeyAndOrderFront method for the plug's window.
[VST] The input boxes seem a bit too high for only one line (they have room for almost two lines).
[VST] The Carbon combo box doesn't seem to react like Cocoa or Windows combo boxes, but I guess that is just the way Carbon's combo boxes work, right?

Ugly VSTi Interface X (beta v0.4)

Again everything works, but there is this one additional nitpick:

[VST] When you use the mouse wheel while the input box is active, the whole window seems to flicker.

GarageBand (v5.1)

Everything works (no additional nitpicks :) ).


So instead I used the code to fix the problems in mine, I didn't see any crashes, but there were problems with focus that oli mentioned above and also things not redrawing right.
Could you please return me the favour, and test ComboV (v1.0.3 beta2, download from here (http://www.martinic.com/combov/downloads/)) on your Mac? If it isn't redrawing correctly I would really like to know.

BTW I noticed that neither the oli nor tale version had my fixes for the mouse right button in them. Have you guys tried your code with a two button mouse? Does it work right clicking to open the edit box? When I tried it I don't think it did, but I have a macmini with a logitec mouse plugged in so maybe that's different from the apple ones?
It simply didn't occur to me to add right-click support. Cmd-click works, so that was good enough for me. But adding right-click is a good idea, I will look into that.

[cc_]

Thanks for checking it out and the detailed comments. I'll try to fix those.

I tried ComboV, only nits I had were in Cubase and Live7. I couldn't find a way of dismissing the edit box with the mouse (clicking outside didn't work) you have to press enter or esc. Also, if you type more than will fit in the edit box it doesn't scroll, the letters just get squished together until there's just one big black blob! I've never seen anything do that before! Probably not a problem in your application though.

And yeah, right click doesn't work in either Carbon or Cocoa. The problem is that OSX doesn't treat it as a modifier, it's a different event.

[Tale]

Thanks for testing. :)

I tried ComboV, only nits I had were in Cubase and Live7. I couldn't find a way of dismissing the edit box with the mouse (clicking outside didn't work) you have to press enter or esc.
Yeah, that is the way it works at the moment. I think will look into that though, because clicking outside the edit box to close it would make my Carbon implementation more consistent with Cocoa.

Also, if you type more than will fit in the edit box it doesn't scroll, the letters just get squished together until there's just one big black blob! I've never seen anything do that before! Probably not a problem in your application though.
I haven't seen that myself, but I will look into that as well.

And yeah, right click doesn't work in either Carbon or Cocoa. The problem is that OSX doesn't treat it as a modifier, it's a different event.
This is on my to-do list.

[Tale]

Yeah, that is the way it works at the moment. I think will look into that though, because clicking outside the edit box to close it would make my Carbon implementation more consistent with Cocoa.
Done. And I have also added left-click to commit behaviour to the Windows version.

I haven't seen that myself, but I will look into that as well.
The "squishing" was caused by the single line flag. I have therefore removed it, although the text still won't scroll, but instead it now wraps to the next line. This does look better though.

This is on my to-do list.
Done.

I have bundled all my modifications and bugfixes in a Git repository, and I have made a list of them on my WDL mini website.

Mini website: http://www.taletn.com/wdl/
Git repository: http://www.taletn.com/WDL.git

[cerberus]

i'm trying tale's wdl, i've found that i want to disable the right-click function for certain controls, or make right-click behave like a regular click; e.g. // a contact switch that hides itself when clicked

class IContactControlHideOnClick : public ISwitchControl
{
public:

IContactControlHideOnClick(IPlugBase* pPlug, int x, int y, int paramIdx, IBitmap* pBitmap)
: ISwitchControl(pPlug, x, y, paramIdx, pBitmap) {
// the standard double click sets-to-default behaviour doesn't make sense for
// IContactControl and leads to fast single clicks getting lost, so turn it off.
mDblAsSingleClick=false;
}
~IContactControlHideOnClick() {}

void OnMouseUp(int x, int y, IMouseMod* pMod);
void OnMouseWheel(int x, int y, IMouseMod* pMod, int d) {} // added (xen) disables mousewheel
void OnMouseDown(int x, int y, IMouseMod* pMod);

};


void IContactControlHideOnClick::OnMouseDown(int x, int y, IMouseMod* pMod)
{
if (pMod->R) { // on right click, do nothing.

}


mPlug->GetGUI()->HideControl(29,true); //hides itself (kIndex number, true)
// mPlug->GetGUI()->HideControl(27,false);

} // rr

void IContactControlHideOnClick::OnMouseUp(int x, int y, IMouseMod* pMod)
{
mValue = 0.0;
SetDirty();
}
and
///////////////////////////////
// A switch that reverts to 0.0 when released. Mousewheel is disabled.
// xen
class NoWheelIContactControl : public ISwitchControl
{
public:

NoWheelIContactControl(IPlugBase* pPlug, int x, int y, int paramIdx, IBitmap* pBitmap)
: ISwitchControl(pPlug, x, y, paramIdx, pBitmap) {
// the standard double click sets-to-default behaviour doesn't make sense for
// IContactControl and leads to fast single clicks getting lost, so turn it off.
mDblAsSingleClick=false;
}
~NoWheelIContactControl() {}

void OnMouseUp(int x, int y, IMouseMod* pMod);
void OnMouseWheel(int x, int y, IMouseMod* pMod, int d) {} // added (xen) disables mousewheel
void OnMouseDown(int x, int y, IMouseMod* pMod);

};

void NoWheelIContactControl::OnMouseDown(int x, int y, IMouseMod* pMod)

{
// PromptUserInput();
mDisablePrompt = true; // disable right click
mValue = 1.0;
SetDirty();
}

void NoWheelIContactControl::OnMouseUp(int x, int y, IMouseMod* pMod)


{
mValue = 0.0;
SetDirty();
}


however, there are some controls for which direct text entry is not appropriate, but i can't figure out how to disable the right click function. e.g. // Bitmap shows when value = 0, then toggles its target area to the whole bitmap
// and waits for another click to hide itself.
class IBitmapOverlayControl : public ISwitchControl
{
public:

IBitmapOverlayControl(IPlugBase* pPlug, int x, int y, int paramIdx, IBitmap* pBitmap, IRECT* pTargetArea)
: ISwitchControl(pPlug, x, y, paramIdx, pBitmap), mTargetArea(*pTargetArea) {}

IBitmapOverlayControl(IPlugBase* pPlug, int x, int y, IBitmap* pBitmap, IRECT* pTargetArea)
: ISwitchControl(pPlug, x, y, -1, pBitmap), mTargetArea(*pTargetArea) {}

~IBitmapOverlayControl() {}

bool Draw(IGraphics* pGraphics);

private:
IRECT mTargetArea; // Keep this around to swap in & out.
};


help here would be appreciated, tia.

[Tale]

If you use a standard IPlug control, then you can disable the user input prompt by calling DisablePrompt(). However, this will not disable right-click altogether, especially not for custom controls. If you want to disable right-click for these, you will need to something like:

class IMyControl: public IInvisibleSwitchControl
{
public:
IMyControl(IPlugBase* pPlug, IRECT* pR, int paramIdx):
IInvisibleSwitchControl(pPlug, pR, paramIdx) { mDblAsSingleClick = true; }

~IMyControl() {}

void OnMouseDown(int x, int y, IMouseMod* pMod)
{
// Ignore right-clicks
if (pMod->R) return;

// To-do: Add left-click code
}
};

[cerberus]

IBitmapOverlayControl has no OnMousDown method, it may defeat the purpose
to add one? in that case i'd still need to get the control to hide itself, which is
all this one is supposed to do...

for the meantime, made a custom version of IBitmapOverlayControl with right-click disabled :
//////////////////////////////////////////////////////////////////

// Bitmap shows when value = 0, then toggles its target area to the whole bitmap
// and waits for another click to hide itself. Right click is disabled.
class IBitmapOverlayNoRightClick : public ISwitchControl
{
public:

IBitmapOverlayNoRightClick(IPlugBase* pPlug, int x, int y, int paramIdx, IBitmap* pBitmap, IRECT* pTargetArea)
: ISwitchControl(pPlug, x, y, paramIdx, pBitmap), mTargetArea(*pTargetArea) {}

IBitmapOverlayNoRightClick(IPlugBase* pPlug, int x, int y, IBitmap* pBitmap, IRECT* pTargetArea)
: ISwitchControl(pPlug, x, y, -1, pBitmap), mTargetArea(*pTargetArea) {}

~IBitmapOverlayNoRightClick() {}

bool Draw(IGraphics* pGraphics);


private:
IRECT mTargetArea; // Keep this around to swap in & out.
};

bool IBitmapOverlayNoRightClick::Draw(IGraphics* pGraphics)
{
if (mValue < 0.5) {
mTargetRECT = mTargetArea;
return true; // Don't draw anything.
}
else {
mDisablePrompt = true; // disable right click (which would bring up a text box for this control)
mTargetRECT = mRECT;
return IBitmapControl::Draw(pGraphics);
}
}


i'd rather have right-click act like left-click for this particular control,
but at least the user won't ever get the default text prompt, which
i think is an inappropriate behavior (for this control).

[cerberus]

i have text entry working, yay!

enjoy a short movie: http://cerberusaudio.com/b/ScreenFlow31.mov

i'm wondering if one could adjust the size of the text boxes?

[Tale]

IBitmapOverlayControl has no OnMousDown method, it may defeat the purpose to add one?
IBitmapOverlayControl probably inherits its OnMouseDown() from a control above it, ultimately from IControl.

i'd rather have right-click act like left-click for this particular control, but at least the user won't ever get the default text prompt, which i think is an inappropriate behavior (for this control).
I agree that user input isn't very useful on some controls. However, fixing this could break existing code. Besides, it is not that hard to customize your own controls, so they behave exactly as you want them to.

i have text entry working, yay!
Cool!

i'm wondering if one could adjust the size of the text boxes?
The text box sizes are hard-coded in IGraphicsWin.cpp, IGraphicsCocoa.mm and IGraphicsCarbon.cpp (look for #define PARAM_EDIT_W).

[olilarkin]

wouldn't it be better if the text box / dropdown RECT was passed as an argument to promptUserInput(), so that the position is changeable? This is what i've done. Also, i think a popup contextual menu would be much neater than a combo box.

oli

[l0calh05t]

wouldn't it be better if the text box / dropdown RECT was passed as an argument to promptUserInput(), so that the position is changeable? This is what i've done. Also, i think a popup contextual menu would be much neater than a combo box.

oli

I like this suggestion as well (although i'd leave the height fixed)
http://www.plugindeveloper.com/03/wide-user-inpu

[cc_]

Personally, I prefer the Combobox - this right click stuff is meant to be a way to give keyboard entry, and a combobox is better for keyboard entry - on osx at least, you can type in the field and it auto completes.

[l0calh05t]

a combobox only really makes sense for enum values. or did you mean a spin box? I don't really like the right-click stuff either, esp for knobs. left-click editable captions are better imo

[cc_]

Yes, comboboxs for enum values. I thought oli was talking about enum values.

[cerberus]

i don't understand a problem i am having where kParams read back from the .rpp
will return with some apparently incorrect values in the lower bits.

on the left is a restored instance, loaded from a saved .rpp. but it was saved in the exact state we see in
the instance on the right, which is a new instance.

the white text and the text box both represent the same kParam, set the same. but
it comes back with some extra digits hanging off the bag end...
http://gyazo.com/d0a098952e714c9db08f5d9ee7f41037.png

the instance on the right is how it should be; this is a new instance, but as we can observe,
on a restored instance it is making some apparent error...
myVariable = GetParam(kParam)->Value();
is giving me funky numbers that are doubles, but never exactly what they seemingly ought to be.
i assume it's reading from the binary chunk in the .rpp.. but i'm not advanced enough to
be able to figure out when and exactly where the error is coming from. but i'm posting it
here on the chance it is a bug related to osx (testing only vst in reaper atm...)

[cerberus]

i've learned here that the bytechunk is declared as a float by iplug...
http://forum.cockos.com/showthread.php?p= 488243&highlight=IPlug stores only floats

i'm not sure how to proceed...
could i use ByteChunk::Put() to the force serialization as doubles?
and if so, how would i go about that?

or would i need to modify the serialize method in iplug?
would using cc_'s modified containers.h file help?

[cc_]

No, my modified containers would not help, that just makes sure projects can be swapped between PPC and Intel without breaking.

If you grab my latest WDL (see the sticky thread) and set:


#define PLUG_DOES_STATE_CHUNKS 1


in your resource.h (or wherever you do that stuff), then you can be sure that it will save your parameters as doubles (in the state chunk).

But, I'm not sure that's the problem. I mean, the value you are trying to save is 0, right? Zero should be zero whether you store it as a float, a double an int or a char!

[cerberus]

thanks cc_ right, i'm not sure i've identified my issue correctly... my workaround
for the problem just asked about was unacceptably weird; there's probably some other
error in my code, e.g. where i may have confused writing normalized kParam values
with a control's defined range, etc.

[cerberus]

well... this is odd.. alpha channel for itext is working in osx, but not on pc?? some kind of turnabout? or a graphics card issue for me? ( we see the known font size discrepancy issue here too):

http://gyazo.com/35405e78ca4149a345c91c73d42a7fb0.png

[cerberus]

another user also gets the bright text... i compiled with the same wdl/iplug source files and headers. could this be a cockos bug?

would someone please verify if alpha channel for text is working properly on the pc platform?

[Tale]

The alpha channel does not work for text in Windows, because IPlug calls the Windows API functions SetTextColor() and DrawText(), and these do not support an alpha channel.

[cerberus]

oh ok. thanks tale!

perhaps we still could emulate alpha channel by using gray out? or even changing the amount of grayout on the fly?

[cerberus]

http://gyazo.com/6a549d50bbed04b105b79a365d309247.png

so i never imagined that i could or would make software for pc...
i don't really know how to use a pc. so thanks to cockos,
and to those who have offered me tips thus far!

[cerberus]

this is getting weird... i see 2 apparent bugs for text boxes in windows only. osx right click works perfectly here.

1. windows is broken in this case.. same code. i made a double-click method to open the text box which does still work in windows.
but the right-click method works only in osx.

http://cerberusaudio.com/b/Win_RightClick_Broken.mov

2. notice that osx text boxes open with the contained text field auto-selected, whereas
windows text boxes require one to re-select what appears to have been auto-selected.
(i think this is a bug, but i am told this is normal behavior for iplug on windows.)

anyone have any windows fixes for text boxes ?

what a strange case of turnabout this is, my text boxes in osx now work like a dream! (but, uh...)

[cerberus]

1. is solved, i think...

it was ok to have PromptUserInput() in the OnMouseUp method in osx, but it seems
that in windows, PromptUserInput() can be called from the OnMouseDown function
or OnMouseDoubleClick functions, but not from OnMouseUp.

[olilarkin]

i noticed a slight problem with the IGraphicsMac/Win PromptUserInput() implementations i.e. in cockos/tales/ccs repos.


int n = pParam->GetNDisplayTexts();
if (n) { ...



if someone has done


GetParam(kGainL)->InitDouble("Gain L", 0.0, -96.0, 12.0, 0.1, "dB");
GetParam(kGainL)->SetDisplayText(-96., "Mute");


they can no longer set the parameter using a text entry, since there is 1 Display Text. Maybe better to do something like


int n = pParam->GetNDisplayTexts();

if (pParam->Type() == IParam::kTypeDouble | pParam->Type() == IParam::kTypeInt) // do text entry
else if (pParam->Type() == IParam::kTypeEnum && n) // do combobox

[Tale]

Yes I agree, that would be better. BTW, a boolean should also show a combo box:

int n = pParam->GetNDisplayTexts();
if (n && (pParam->Type() == kTypeEnum || pParam->Type() == kTypeBool)) { ...

[Tale]

I have updated my Git repository (http://www.taletn.com/WDL.git), now only boolean and enum parameters use a combo box when prompting for user input.

[olilarkin]

i didn't try your code, but i took a look at the changes. I think you also need to test the parameter type in IGraphics::SetFromStringAfterPrompt() rather than just the number of display texts. I think the bug i mentioned above will still happen.

[Tale]

My updated code in SetFromStringAfterPrompt() checks if there are any display texts. If so, then it tries to map the user input string to one of the display texts using MapDisplayText(). If this succeeds, then the int that corresponds to the display text is used. If the user input string can't be mapped to a display text, then the input string is converted to a number using atof(). No bug here (at least, I think). :)

double v;
bool mapped = pParam->GetNDisplayTexts();
if (mapped)
{
int vi;
mapped = pParam->MapDisplayText(txt, &vi);
if (mapped) v = (double)vi;
}
if (!mapped)
{
v = atof(txt);
if (pParam->DisplayIsNegated()) v = -v;
}
pControl->SetValueFromUserInput(pParam->GetNormalized(v));

[olilarkin]

ah ok, missed that