Trying to use WDL in a stand alone Windows Program

[mschnell]

In the end I'd like to do a Reaper extension, but in my book it's a good idea to know your tools before starting the decent work.
So I'd like to do a very simple Windows Desktop application and use the WDL GUI stuff.

I understand, that Reaper itself uses this paradigm and this is why some Mac users are unhappy with the "windowish" look of Reaper. And so I recon porting the application / plugin to Mac should be rather easy when as much as possible is done using WDL instead of directly interfacing th OS.

I am decently fluent in ANSI C (and EEL, and object Pascal, and, ...) but never did anything with C++, yet, so please be patient.

I understand I need to (or should) use Visual Studio as an IDE for Windows programming using WDL.

I already have Visual Studio running and did a test program that is supposed to instantiate a class from WDL.

I added the WDL directories to the "include path", "source directories", and other variables and get this:

I added just two lines to my rather empty testing project main cpp file; one #include and one just creating a variable for the WDL class.

Some WDL cpp files get compiled, including the one that holds the classes initialization functions. (I only do know this because warnings are shown, but I don't find any .o or .d files .)

I get no compiler errors from my main cpp file, hence the included does work decently.

Then I get a linker error stating that the constructor and destructor functions for the class are not found. (Seemingly C++ secretly constructs calls for these when I simply declare a variable for that class.)

Hence obviously the project's linker script (or whatever Studio uses top define the make process) is not adapted to see the results of compiling the cpp files residing in the WDL directories.

Any tips ?

-Michael

[Xenakios]

Maybe best to mostly forget about WDL at this point and just use the win32 API functions to get the application going. WDL offers nothing particularly special for GUI anyway. (The virtual windows stuff is mainly to allow doing GUIs which need a lot, like thousands, of small GUI controls without spending as many Windows handles.)

For example, if you take a look at the Cockos Osciibot code, the GUI is done with the win32 API. There was no need for Justin to use the WDL Virtual Windows because the GUI doesn't need many GUI controls.

The table control in the SWS LiveConfigs is just a SysListView32 from win32, not for example a collection of smaller controls done with the WDL Virtual Windows.

Regarding the build errors : you should include and build only what you are going to be using. It's not a great idea to for example to try to compile all the .cpp files in WDL on Windows, as some of those are going to be macOs/Linux specific. Some things will require you to link to additional system libraries.

[mschnell]

Originally Posted by Xenakios

WDL offers nothing particularly special for GUI anyway.

I did not hope for any features but for allowing for easy portability to Mac (and Linux), once the thingy runs in Windows,

Originally Posted by Xenakios

There was no need for Justin to use the WDL Virtual Windows because the GUI doesn't need many GUI controls.

Obviously. But as you stated above, the WDL GUI stuff does not provide much content regarding features, anyway. But maybe not using WDL GUI is exactly why there is no OSCIIBot for mac.

Originally Posted by Xenakios

The table control in the SWS LiveConfigs is just a SysListView32 from win32, not for example a collection of smaller controls done with the WDL Virtual Windows.

Thanks a lot for looking this up for me and pointing it out here !

But (other than the initial discussion in the "extensions" forum) this thread here is about getting started with a test program using WDL at all - be that with out without using the GUI features WDL provides. I in fact did use the WDL GUI class as a primary example, but I might just as well try out any other class provided by WDL to get started. Very obviously I will see the same linking error as I did before. I'll do this test later this day.

Originally Posted by Xenakios

Regarding the build errors : you should include and build only what you are going to be using. It's not a great idea to for example to try to compile all the .cpp files in WDL on Windows, as some of those are going to be macOs/Linux specific. Some things will require you to link to additional system libraries.

Am I wrong assuming that I need to compile the appropriate cpp files that come with the WDL distribution before they can be used in (linked to) my main.cpp" code ?

The error I see very obviously is that the linker does not find the (constructor and deleter) functions for the class, even though the compiler did handle the cpp files that provide those (because I included the appropriate directories in WDL in the source file tree of the project). I know this because I did see warnings, but no error messages from these files.

Maybe you are right that *if* the functions would get linked, I will see linker error messages about not finding OS depending libraries they need, but as of now, I am not yet at this point.

Right now I don't see a way to use any WDL functionality in my project, as I don't know how to configure Studio to actually link to WDL.

Thanks again,
-Michael

[Tale]

Originally Posted by mschnell

I did not hope for any features but for allowing for easy portability to Mac (and Linux), once the thingy runs in Windows

Well, SWELL emulates (part of) the Win32 API on macOS/Linux, so if you don't do anything too outlandish, you will probably still be able to port your code.

[olilarkin]

There is a SWELL example project here https://github.com/justinfrankel/WDL...sample_project

Also a LICE test project
https://github.com/justinfrankel/WDL.../WDL/lice/test

The iPlug2 app wrapper also uses this stuff which might be helpful to look at.
https://github.com/iPlug2/iPlug2/tree/master/IPlug/APP

[olilarkin]

BTW if you want to make a reaper extension, iPlug2 can do that

https://github.com/iPlug2/iPlug2/tre...eaperExtension

[mschnell]

I'll take a look at all of theses....

But right now I am fighting with Visual Studio.
- I created a class variable for the WDL string functionality. This does work nicely, supposedly because all code far this is in the appropriate WL header file.
- I tried to create a variable for the "directory" handling WDL feature -> I get linker "not found" errors.
- I tried (even though I don't suppose this is a decent way to go) to include the WDL cpp file that holds the functions for that class in the project file list in Studio. -> The file does compile, but I get even more linker "not found" errors
What is a decent way to make the WDL cpp files (or whatever might be generated from them) known to the Visual Studio project ?

-Michael

[Xenakios]

Originally Posted by mschnell

What is a decent way to make the WDL cpp files (or whatever might be generated from them) known to the Visual Studio project ?

You just add all the needed .cpp files and possible additional libraries. (Often the linker errors are because of missing system libraries, not because of missing .cpp files in the project.) These are not documented anywhere, you will just have to manage it somehow.

Which directory handling thing specifically are you trying to use?

[mschnell]

What do you mean by "adding files" ?

What do you mean by "adding libraries" ? (What kind of files how to "add" them ? )

I have a directory "WDL" below user...\source\ that hosts what is distributed by the GIT. The .h files residing there are happily used by my project after enhancing the include path in the project properties. (Seems to work in Studio as I know from Eclipse. )
I have another directory below source that holds my testing project.

I would not like to copy the cpp files in my project directory, but I suppose there is a way to aloow such files to be found and compiled in place. (In fact I already even saw warning messages from such files, but there are no OBJ (or similar) files.) And finally the compiled being used by the linker.
Or alternatively in a first step have the WDL files compiled to a binary library and later used when linking my project.

Thanks,
-Michael

[mschnell]

Originally Posted by Tale

Well, SWELL emulates (part of) the Win32 API on macOS/Linux, .

I supposed this.

Is the paradigm to use in the main project always to use SWELL calls instead of Windows API calls and then SWELL when compiled for Windows just forwards those, while when compiled for Mac or Linux emulated their functionality appropriately (resulting in portable source code in the main project) ?

This is exactly what I would like to make use of.

-Michael

[Xenakios]

Originally Posted by mschnell

What do you mean by "adding files" ?

What do you mean by "adding libraries" ? (What kind of files how to "add" them ? )

Adding the needed .cpp files to be compiled with your project. For example the WDL audio resampler requires not only the resample.h file to be in the include path of the project, but also the resample.cpp file has to be added into the Visual Studio project source files to be compiled.

Libraries on Windows for Visual Studio come in the form of .lib files. When you use the win32 API functions, often libraries like Shell32.lib, advapi32.lib, winmm.lib or Ole32.lib will need to be added into the project. (In the project settings : Linker->Input->Additional dependencies.)

Note also that WDL/Swell/Reaper don't support "Unicode character set" projects, you need to set your Visual Studio project to use the "Multi-byte character set" in the project settings, "General->Character set" field.

[Xenakios]

Originally Posted by mschnell

Is the paradigm to use in the main project always to use SWELL calls instead of Windows API calls

No, the paradigm is to write win32 code, possibly using the API call versions provided by the WDL win32_utf8.h header when needed. (That would depend on if you want to support Unicode text.) Swell is then used on macOs and Linux to build the win32 API code. You need to be careful you don't use any win32 API features not supported by Swell.

[mschnell]

That is a shame. It would be really nice to have SWELL provide the appropriate dummy functions to be used in the Windows built.

I did some initial steps to dive in this issue:

I tried to compile the line
MessageBox(NULL,"hello world","a",0);
as found in \swell\test.cpp
Without using WDL at all.

I found that this can't be compiled in a Windows environment (for the Windows API). You either need to do
MessageBoxA(NULL,"hello world","a",0);
or
MessageBox(NULL,L"hello world",L"a",0);

Microsoft obviously did a great job to make programmers pull out all their hair

Instead of either keep the (ANSI-) functionality with the old API function name or have the compiler do wide char with "hello world", the messed up backwards compatibility completely when introducing wide char.

So obviously the SWELL syntax
MessageBox(NULL,L"hello world",L"a",0);
can't be used for windows.

Maybe inserting
#ifdef _WIN32
#define MessageBox MessageBoxA
#endif

or similar somewhere would suffice...
-Michael

[Xenakios]

Regarding the Unicode etc mess, like I mentioned above, you need to set the Visual Studio project to be in the Multibyte Character mode. (The default is Unicode, which isn't compatible with WDL, Swell nor Reaper.) Then the code can be the same for both Windows and Swell, for example you can just use the MessageBox function (without the A or W suffix) the same way for all platforms, *if* you don't want to support Unicode characters. *If* you want Unicode support, you will have to rely on the Cockos provided functions from the win32_utf8.h header. For example, to make message boxes you would need to use the Cockos provided function MessageBoxUTF8 from that header. (Of course the related win32_utf8.c file also needs to be built in your project.)

[mschnell]

Originally Posted by Xenakios

Multibyte Character mode.

I'll try to find this option ASAP...

Originally Posted by Xenakios

(Of course the related win32_utf8.c file also needs to be built in your project.)

I'll try this ASAP...

BTW.: Before I dive even deeper in the Visual Studio oddities: Is it possible / sensible to use Eclipse and GCC instead of the M$ products for using WDL and/or for creating a Reaper extension ?

-Michael

[Xenakios]

Originally Posted by mschnell

BTW.: Is it possible / sensible to use Eclipse and GCC instead of the M$ products for using WDL and/or for creating a Reaper extension ?

Not possible on Windows. (Technically you could probably do a standalone application with mingw etc, but Reaper extensions require using the Microsoft compiler.)

[mschnell]

OK.

Thanks for the clarification.

IMHO bad news, as I every day do use Eclipse and the mingw -compiled GCC suite to do executables for embedded (non-Intel type) CPUs.

-Michael

[mschnell]

BTW. I now see that the included swell.h in a Windows project reduces itself to a dummy, and because the same names as the Windows API functions (which I did not ever use before starting this) are used, the same main code automatically will compile as well for Windows "Multibyte" as for Mac or Linux.

-Michael

[mschnell]

Originally Posted by Xenakios

you need to set the Visual Studio project to be in the Multibyte Character mode.

I found that to use

MessageBox(NULL,"hello world","a",0);

which is compatible with swell, I need to set the project to Character mode."not set" (instead of "multibyte" or "Wide char.

But now this works.
-Michael

[mschnell]

Originally Posted by Xenakios

The table control in the SWS LiveConfigs is just a SysListView32 from win32, not for example a collection of smaller controls done with the WDL Virtual Windows.

As suggested I took a look at SWS and the most basic GUI Window control seems to be the

class SWS_ListView
So I copied the class definition from sws_wnd.h in a .h file in my new "Desktop application" type project, and after copying some more definition lines from that file, adding some files in the sws and WDL directories to the include search path, and doing some tweaking the thing compiles and runs (of course without any additional functionality).

Then I added

SWS_ListView my_ListView;

to my .cpp file.

After adding sws\sws_wnd.cpp to the project, the thing does compile (and I do have a sws_wnd.obj file) .

But again I get a linker error that the "standard constructor" is not available. (But no message about a destructor.)
Am I right understanding that
in sws_wnd.cpp:

SWS_ListView::SWS_ListView(HWND hwndList, HWND hwndEdit, int iCols, SWS_LVColumn* pCols, const char* cINIKey, bool bTooltips, const char* cLocalizeSection, bool bDrawArrow)
:m_hwndList(hwndList), m_hwndEdit(hwndEdit), m_hwndTooltip(NULL), m_iSortCol(1), m_iEditingItem(-1), m_iEditingCol(-1),
  m_iCols(iCols), m_pCols(NULL), m_pDefaultCols(NULL), m_bDisableUpdates(false), m_cINIKey(cINIKey), m_cLocalizeSection(cLocalizeSection),m_bDrawArrow(bDrawArrow),
#ifndef _WIN32
  m_pClickedItem(NULL)
#else
  m_dwSavedSelTime(0),m_bShiftSel(false)
#endif
{
    memset(m_oldColors,0,sizeof(m_oldColors));
...

is this constructor ?

Seemingly Studio again declines to use sws_wnd.obj for while linking ?!?!?

Any further tips ?

-Michael

[Xenakios]

Originally Posted by mschnell

As suggested I took a look at SWS

I don't know anything about how they *use* the win32 SysListView32 , I just quickly looked at how it is *created* in the LiveConfigs. Actually, maybe the current code doesn't even use the win32 one and it's all custom code? (The stuff in the win32 resources file could be a leftover that isn't used anymore.)

[mschnell]

I feel that the suggestion was very viable, anyway. I and I feel that I got to some sensible landmark on my quest by this.

Now the cliffhanger is just C++ / Visual Studio questions.

1) Is the code I found in sws_wnd.cpp and showed above indeed the (a) constructor for the class SWS_ListView ?

2) what is a "default" / "standard" constructor (I installed get a German error messages here. )

3) (Why) does Studio not see/use the file sws_wnd.obj for while linking ?

(What is "the win32 resources file" and why/how do you think it might harm ? )

Thanks a lot for your comments !
-Michael

[mschnell]

Silly me finally found out what I did not grasp in the C++ "class" paradigm (which does not exist in ANSI C and is different in Object Pascal and hence new to me).

I found that when defining a variable with a class type, a constructor of that class is automatically called (no idea when exactly it will be called when creating a static variable / instance instead of heap or stack based).

If no parameters (in parentheses) are given with the variable definition, a constructor with no parameters is to be called (even if no such thing is in the class definition) - otherwise a constructor with the appropriate parameters is called. When the class definition does not feature a constructor with no parameters, a "default" constructor is assumed. But as there is no implementation for a parameter-less constructor function in SWS_ListView, I get a linker error.

After learning this I found that I in act don't want such a variable, but a variable with a pointer to the class instance. And such a pointer variable does not trigger the call of a constructor, but this can be done manually by "new".

OK this makes sense and works. But...
After this, the linking process continues instead of breaking up. Hence I see what the file sws_wnd.cpp, that I included in the project, requires. It turns out that by adding more source files to the project to take care of the open references seems to result in the need to include all source files as well from sws as from WDL in the project. This does not seem to mke any sense at all.

Any further tips ?

Thanks,
-Michael

[Xenakios]

Originally Posted by mschnell

It turns out that by adding more source files to the project to take care of the open references seems to result in the need to include all source files as well from sws as from WDL in the project. This does not seem to mke any sense at all.

That's a common problem with projects that were not designed to be reused in other contexts. You may in fact need to have all or almost all of the source compiled with your project.

[mschnell]

That would be nearly 1000 files. I don't think that makes sense.

I'll try to somehow extract what is necessary ...
OTOH WDL is called a library (i.e. something to be used in another cointext). Hence it should be possible to compile it to a linkable object (a static library, i.e. one or more *.lib files) with some kind of limited effort.

-Michael

[Xenakios]

Originally Posted by mschnell

That would be nearly 1000 files. I don't think that makes sens.

I'll try to somehow extract what is necessary ...
OTOH WDL is called a library

WDL, sure, it is a library and was designed to be used without usually having to include and compile too much stuff. But you mentioned the SWS plugin code base too...That is not reusable library code necessarily.

[mschnell]

OK.

So the way to go would be to extract from the sws source code in a new project whatever snippet is to be used, while usinig WDL as a library.

But now I first need to find out how to compile WDL to a (set of)*. lib file(s). Maybe searching this forum or available docs on WDL might reveal the method.

-Michael

[Tale]

Originally Posted by mschnell

But now I first need to find out how to compile WDL to a (set of)*. lib file(s). Maybe searching this forum or available docs on WDL might reveal the method.

Why would you want to do that i.e. why not simply add the headers/source files you need to your project?

[mschnell]

Originally Posted by Tale

Why would you want to do that i.e. why not simply add the headers/source files you need to your project?

Of course I added the appropriate directories to the include search path and this does work fine.

But I don't see a way how to "add" 700 WDL cpp files to the "to the project" to have them compiled. In fact I added same 20 and then gave up. Does Visual Studio provide a way to "add" complete directories ? (I do know a bit about GNU make files but Visual Studio seems to provide it's own propriety - opaque to me - make mechanism.)

-Michael

[Tale]

Originally Posted by mschnell

But I don't see a way how to "add" 700 WDL cpp files to the "to the project" to have them compiled.

If that is so, then how are you going to build a LIB? This will also mean creating a project for it, and adding those files.

BTW, I don't think WDL includes anywhere near 700 files. Also, WDL doesn't include just C++, but also C (e.g. FFT).

But what I really meant is: Why would you want to compile all WDL files? WDL includes customized versions of zlib and libpng, which are libraries themselves. If you really, really want to use LIB files, then IMO it would make more sense to build zlib and libpng outside of WDL.

However, the whole point of WDL is that you don't need to build LIB files, but instead just add the C/CPP source files that your project needs.

Originally Posted by mschnell

In fact I added same 20 and then gave up. Does Visual Studio provide a way to "add" complete directories ? (I do know a bit about GNU make files but Visual Studio seems to provide it's own propriety - opaque to me - make mechanism.)

I can't really help you there, because although I do use the VS toolchain, I don't really use its IDE or project files. Instead I just use NMAKE makefiles, and build everything from the command line.

[Xenakios]

Originally Posted by Tale

BTW, I don't think WDL includes anywhere near 700 files.

It does have about 400 .h, .c and .cpp files...I wouldn't be surprised if the SWS plugin code base has dependencies to almost all of that. The SWS plugin also has lots of code itself and some additional dependencies like libtag.

[mschnell]

Originally Posted by Tale

However, the whole point of WDL is that you don't need to build LIB files, but instead just add the C/CPP source files that your project needs

I don't know what this conclusion is derived from, but I'll accept it and re-try my effort in compiling an as small as possible project containing SWS_ListView by creating my own files to hold whatever is necessary from the sws directories, and adding the files to the project that are necessary from the WDL directories.

In my ignorance I assumed that there should be a halfway automatic method to turn a bunch of *.c and *.cpp files in a binary library.

(My copy of sws has 170 *.c* files, and my copy of WDL has 203 *.c* files. I seemingly included the .git directory with the first count )

Thanks for commenting !
-Michael

[mschnell]

In fact I was able to do a Desktolp application that actually creates an instance of the SWS_ListView class by
my_ListView_p = new SWS_ListView(hWnd, hWnd, 10, myColums, "INIKey", FALSE, "LocalizeSection", true);

So that I can use this in callbacks by the minimal GUI of the executable (e.g.
colcnt_ = my_ListView_p->GetColumnCount();

To do this, I needed to do some queer tricks, use some WD header files and include just a few files in the project:

win32_ut8.c from WD
some extracts form sws_util.cpp, Menus, from swd
m_sws_ListView.cpp ontaining what actually is necessaryto implement ListView

As the ListView code calls get_ini_file() from the reaper API, I needed to do a fake implementation for this. I suppose when actually doing a reaper extension this is going to be linked back inito Reaper.

Now I am struggling with finding out what to do to make Windows actually show the ListView object.

-Michael

[Xenakios]

Originally Posted by mschnell

Now I am struggling with finding out what to do to make Windows actually show the ListView object.

Try experimenting with ShowWindow, SetParent and SetWindowPos win32 API functions. Also, the HWND you pass into the SWS_ListView constructor must be the HWND of the list view itself, of course not for example your application windows's HWND.

edit : so, to clarify : the SWS_ListView does not itself create the needed SysListView32, you need to manage that somehow yourself. I don't know why the SWS_ListView is implemented that way, a properly designed GUI class would of course internally create/show etc the list view.

[WyattRice]

I did a listbox thing for an extension for DDP Marker Editor.

Maybe you could make some use of the code.

I had alot of help doing it.

Here's a link you can check it out.

https://github.com/WyattRice/reaper-DDP-Marker-Editor

Regards,Wyatt

[Xenakios]

Originally Posted by WyattRice

I did a listbox thing for an extension for DDP Marker Editor.

Maybe you could make some use of the code.

Just to clarify for mschnell, that code is not using any of the SWS_ListView code, it's based on directly interfacing with the win32 API.

[mschnell]

Thanks a lot for all these suggestions !
I do know that getting SWS_ListView going might ask for some extra effort. I had this idea, as the LiveConfigs API is based on same and my intention is to create something looking rather similar. Moreover much of the functionality or LiveConfigs also is a model for the intended Reaper extension and hence understanding ho sws works internally will be useful.

-Michael

[mschnell]

Being new to Windows API stuff, just some basic questions that might be easy to answer.

I understand that SWS_ListView is supposed to either create a new Window or to take over an existing window.

When instantiating the class, I provided it with the window handle I got with the GUI event (message-callback) that was called (after the user hitting a menu item). Is this a possible way to go ? (In fact nothing visible happens at that point.)

I supposed I need to do something with the class to "show" it. But I don't find any function provided by the class that might do that. Do I need to call some Windows API function on the Window handle to make visible updates to what the window handle denotes ?

The simple example code (provided by Studio) has is a kind of "paint" message-callback. but same is called only once when the program starts.

-Michael

[cfillion]

SWS_ListView is an abstraction layer for the Win32 List View API. It doesn't deal with entire windows, it takes a handle to a list view control.

https://docs.microsoft.com/en-us/win...trol-reference

[Xenakios]

Originally Posted by mschnell

I understand that SWS_ListView is supposed to either create a new Window or to take over an existing window.

When instantiating the class, I provided it with the window handle I got with the GUI event (message-callback) that was called (after the user hitting a menu item). Is this a possible way to go ?

No, like I explained above, *you* have to create the win32 SysListView32 first and then pass the handle of that to the SWS_ListView object when constructing it. The SWS_ListView never takes care of creating the win32 object for you. You can do it yourself either by using a dialog resource file or programmatically with CreateWindow(Ex) on Windows. (IIRC you have to use some other function with SWELL to create controls manually.)