Is compilation on VS Express possible somehow?

[arseniiv]

Wiki states OpenMPT's sources is compilible on Visual Studio not less than Standard edition because of lack of MFC in Express. Could it be possible do something on my side to compile somehow? (This question may be strange, I don't know much about MFC.)

(Particularly, I'd wanted to try to implement plugin tags from my own request #541 Don't know if I actually can.)

[Rakib]

MFC is the GUI-library. Dont think you can implement that without any GUI-elements.

But can you test if it works with this version, Microsoft doesnt make express versions anymore.
http://www.visualstudio.com/en-us/products/visual-studio-community-vs

[Saga Musix]

You can compile libopenmpt with VS express since it naturally doesn't have a GUI, but OpenMPT itself requires MFC for its GUI. As Rakib points out, you should give the community edition a try, I think that it actually includes MFC but I am not 100% sure. Otherwise, there's always the trial version for the Pro version available.

[Diamond]

Visual Studio Community?  Nice!  Almost makes me want to code something.  And yes, based on a few discussions I have seen, it does include MFC.

[arseniiv]

But can you test if it works with this version, Microsoft doesnt make express versions anymore.
http://www.visualstudio.com/en-us/products/visual-studio-community-vs

Oh, thank you! I didn't know about Community version yet.

As Rakib points out, you should give the community edition a try, I think that it actually includes MFC but I am not 100% sure.

Indeed it does, as I see in install options now.

Diamond, +1.

Thanks all, I'm going to update my Express. Next step will be acquiring Steinberg's VST SDK...

[arseniiv]

Finally I've came back to OpenMPT's source and even managed to build it! By looking at the MFC-based code, It seems I'm going to have a hard time adding even a non-functional text field.

[Approximately an hour later.] I've added two controls to 'Plugin settings' dialog and after rebuild it seems code for their placement is written correctly. Oh, a small victory... (Hooray.)

And there's a question: doesn't someone mind me using VST Plugins.Plugin%d.Tags settings to store plugins' tags? (Just planning—I haven't written nothing more than dialog resizing code yet.)

[Saga Musix]

By looking at the MFC-based code, It seems I'm going to have a hard time adding even a non-functional text field.

Actually that's super easy because it's not using any code but dialog resources almost exclusively (which brings nice advantages like automatic DPI-awareness).

And there's a question: doesn't someone mind me using VST Plugins.Plugin%d.Tags settings to store plugins' tags? (Just planning—I haven't written nothing more than dialog resizing code yet.)

Well, they'd definitely require an extra field there. How do you want to integrate this though - multiple tags per plugin, or user-configurable plugin categories?

[arseniiv]

Categories would be nice, too, but tags are the first. I roughly imagine what's to be done here already.

If we don't allow space or other char in tags, we may free yourself from representing all tags of a plugin by set, list, array etc., and we can use ordinary string of form " tag1 tag2 ... tagN " (with spaces at the ends) instead, and search for a substring " sometag " to test if specified tag is in there. I think, a plugin would rarely have more than ten or so tags, so it's not very slow compared to binary search in a string array. So:

• In VstPluginLib, add a field for tag string and code to read it from app settings.
• In CSelectPluginDlg is the rest. Later I'll maybe try also to add a small multi-select list with all currently used tags to select from (as in GIMP). Its state would mirror (and be mirrored by) value of Tags or Filter field.
(Hum, I thought this list would have more than two lines.)

Soon I'll try this and write here something new after!

Ah, and there is another question. I haven't any intention to disrupt existing ordinary search in plugin names, therefore in filter string there must be some difference in tags and mere substring. What I've thought of is to prefix tags by + or some other easy-to-type thing. If it's +, we could then also use - to exclude specified tags from plugins to find. I doubt there's any reason one's need to use + or - at the start of a tag, and there's no apparent reason to search for +- or --starting substring of a plugin name either. So how's it?

[Saga Musix]

If someone enters tags for their plugins, I doubt that they would mind if they were searching for both tags and plugin names at the same time (and usually the two would be rather distinct anyway I imagine), but the most accessible approach would probably be to have two checkboxes, "Find in: [x] Plugin names [x] Tags".

[arseniiv]

Oh, cool way! Thank you, when I'll return to this code, I'll try this.

[arseniiv]

Oh, finally, I think, I wrote something, being returned to this project two days ago. Unfortunately, linker isn't agree with me and says

error LNK2001: unresolved external symbol "class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > __cdecl ConvertStrTo<class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > >(class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > const &)" (??$ConvertStrTo@V?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@@@YA?AV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@ABV01@@Z)
C:\Users\123\Documents\Visual Studio 2013\Projects\modplug-code-4720-trunk\OpenMPT\mptrack\SelectPluginDialog.obj

AFAIK that long name means the same as std::wstring __cdecl ConvertStrTo<std::wstring>(std::wstring const &). I saw some calls to ConvertStrTo in setting read/write code, and I commented out the one and only call to setting writing method in SelectPluginDialog.cpp, but this doesn't solve the problem. (So I uncommented it back.)

So, I tested just UI resizing code when there was only it, and now I can only post here some changed files. Maybe someone can understand what the linker meant in context of these.

And somehow I forgot what OpenMPT version is a base for current changes, so I hope it's possible to determine it by download time—it should be approx. 17 January 2015.

(Oh, C++ and MFC are so hard on me... I hope I didn't make any bad design decisions.)

[Saga Musix]

AFAIK that long name means the same as std::wstring __cdecl ConvertStrTo<std::wstring>(std::wstring const &). I saw some calls to ConvertStrTo in setting read/write code, and I commented out the one and only call to setting writing method in SelectPluginDialog.cpp, but this doesn't solve the problem. (So I uncommented it back.)

Yes, it means that ConvertStrTo is not specialized for std::wstring - because converting a string into a string wouldn't make much sense (at least until now it didn't).

Creating a patch rather than just copying files would have been more favorable, but I checked out that old revision you were using, copied the files over and created a patch against it. I'll try looking at the stuff in the next few days and try to update it for the latest revision:

EDIT: Patch updated against the current trunk revision

[manx]

I have not yet looked in detail at the changes, just some quick observations.

1:

Oh, finally, I think, I wrote something, being returned to this project two days ago. Unfortunately, linker isn't agree with me and says

error LNK2001: unresolved external symbol "class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > __cdecl ConvertStrTo<class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > >(class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > const &)" (??$ConvertStrTo@V?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@@@YA?AV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@ABV01@@Z)
C:\Users\123\Documents\Visual Studio 2013\Projects\modplug-code-4720-trunk\OpenMPT\mptrack\SelectPluginDialog.obj

That particular problem has long been fixed. See r4843 and r4854, which is one of very many reason why you should always work against the latest source version, in particular if you intend to provide modifications.

2:
Please use our proper string type for such things, which would be mpt::ustring. That also avoids the need to provide any separate SplitW function. All the different string types and a guide to choose the most suitable one is provided at the top of common/mptString.cpp.

3:
As Saga Musix already noted, PLEASE provide a patch instead of the modified files of any particular (or even unknown) base version. It makes the life for everyone wanting to help way easier.

[arseniiv]

Creating a patch rather than just copying files would have been more favorable, but I checked out that old revision you were using, copied the files over and created a patch against it. I'll try looking at the stuff in the next few days and try to update it for the latest revision:

Oh, thank you!

I just haven't installed VCS OpenMPT uses yet, it's not good, of course...

which is one of very many reason why you should always work against the latest source version, in particular if you intend to provide modifications.

Pretty convincing.

2:
Please use our proper string type for such things, which would be mpt::ustring. That also avoids the need to provide any separate SplitW function. All the different string types and a guide to choose the most suitable one is provided at the top of common/mptString.cpp.

OK, thank you. Next time I'll look there.