Problems compiling the latest version of IPlug2

Today I decided to upgrade IPlug2 to the latest version from https://github.com/iPlug2/iPlug2.
When trying to compile example in “iPlug2\Examples\IPlugEffect\IPlugEffect.sln” in Microsoft Visual C++ 2019, I got a build error: lnk2001 unresolved external symbol "“public: static class std::locale::id std::codecvt<char16_t,char,struct _Mbstatet>::id” (?id@?$codecvt@_SDU_Mbstatet@@@std@@2V0locale@2@A)"
I do not know how to fix this error, since the previous versions of IPlug2 were assembled without any problems from Visual Studio.
I would be grateful for any help in solving this problem.
P.S. There is no way to roll back the last version.

of course you can roll back… it’s called version control. You can revert this commit https://github.com/iPlug2/iPlug2/commit/57cc46b435c57395679f4abb9f1ab4c1de897fd7

This error is todo with some modifications to the text entry control. i don’t have the error here, but i’ll have a look.

Thank you. Rollback from the last commit fixed the problem.
However, for what reason is the last commit not going to? I have a clean Visual Studio without third-party libraries and components, since I use it exclusively for building plug-ins.

And where did the void GrayOut (bool gray) method go?
How can I now compile my own components where this method is overrided?

GreyOut() became SetDisabled().

Are you an iPlug2 sponsor yet?

In general, all these constant renaming methods are not good. Which makes us periodically redo the source code. Is it really impossible to take as a basis any standard set of methods, for example from Delphi VCL/FMX, where the names of the methods have not been changed for more than a decade, and this is very convenient.

Unfortunately, my monthly income is only about $130, like most of the inhabitants of Russia, where the state is ruled by dictator Putin. This money is barely enough so as not to starve to death, so there can be no question of any sponsorship in such a situation. :wink:

Well I hope you can appreciate I give you quite a lot of help on the forum.

I put the majority of the work into this project so I reserve the right to be a benevolent dictator and I’ll rename whatever methods however I like. In this case it’s obviously the right change. If it inconveniences you, sorry about that, you get what you pay for I guess. Don’t really have time to worry too much about backwards compatibility with iplug1 codebases

regarding the original error: are you on the latest version of vs2019?

if not, can you try with the very latest version and let me know if that fixes the link error with std::codecvt ?

We are colleagues and are engaged in a common cause. As soon as my business gets better, I can help sponsor the project. :grinning:

I made my fork from the project and I can adapt it at my discretion. At the moment I am studying C++ and therefore I apologize for asking too many questions. If you have questions about programming for the Object Pascal (On which I have been programming for over 20 years), I am glad to help you completely free of charge. :wink:

don’t think i’ll be doing any pascal programming this lifetime but thanks for the offer ! :slight_smile:

By the way, in the latest version of IPlug2, ITextEntryControl is not functioning correctly.
For example, when you press the NumPad keys, letters are displayed instead of numbers, and also when the Shift key behaves like a space.
I commented out this piece of code in IPlugVST2.cpp:
/*
case effEditKeyDown:
case effEditKeyUp:
{
char str[2];
str[0] = static_cast(idx);
str[1] = ‘\0’;

      int vk = VSTKeyCodeToVK(value, idx);
      int modifiers = (int)opt;

      IKeyPress keyPress{ str, static_cast<int>(vk),
                          static_cast<bool>(modifiers & MODIFIER_SHIFT),
                          static_cast<bool>(modifiers & MODIFIER_CONTROL),
                          static_cast<bool>(modifiers & MODIFIER_ALTERNATE) };

      bool handled;
      if (opCode == effEditKeyDown)
        handled = _this->OnKeyDown(keyPress);
      else
        handled = _this->OnKeyUp(keyPress);

      return handled ? 1 : 0;
    } */

In this case, the processing of keystrokes began to come up in IGraphicsWin.cpp. The indicated bugs disappeared. :wink:
Now I’ll check to see if this bug appears in the VST3 version …

thanks. Please make an issue at github, rather than posting on an unrelated thread

This is taking into account the rollback of the last commit. Maybe this works fine for you with UTF16. So test my hypothesis.