WIN10 Simple sample from outside WXW environment available?

[vcf]

Hi all,

does anyone have a small simple (maybe template type) example
that works well form outside the "standard" WIN10 WXW paths (make, vc,
cb or devcpp style accepted)?

If so please provide together with comp / IDE versions, environment
variables and compiler / linker options.

Just need a small graphic window with a message to link into
another project - nothing more ... ((

Quarreled for three days now with all of the mentioned
building possibilities and half a dozen of combinations of comp and
IDE with miriads of comp and linker options but each and every one
runs me in deep hurdles.

Things worked much better under XP and 8.1 - maybe also a prob
of WIN10?!? ...

Start to get nervous and think about looking for another graphic
program in spite I loved WxW since nearly 20 years now.

Thanks a lot. - Regards - Volker

[PB]

Once again, Windows version is basically irrelevant for building both the library and your application, as long as it is a supported one (XP-10).

I believe that file WXWIN/docs/msw/install.txt in the "Building Applications Using wxWidgets" section sufficiently describes those few simple steps needed to add wxWidgets to your application. I would follow the instructions at the end of the section, so you do not need to add the libraries by hand:

(Assuming you have set the environment variable WXWIN properly before you started MSVS)

Independently of the compiler and make/IDE you are using you must do the
following to use wxWidgets sources under the directory $WXWIN (notice that
different tool chains refer to environment variables such as WXWIN in
different ways, e.g. MSVC users should use $(WXWIN) instead of just $WXWIN):

* Add $WXWIN\include to the
- compiler
- resource compiler
include paths.
* Define the following symbols for the preprocessor:
- __WXMSW__ to ensure you use the correct wxWidgets port.
- _UNICODE unless you want to use deprecated ANSI build of wxWidgets.
- NDEBUG if you want to build in release mode, i.e. disable asserts.
- WXUSINGDLL if you are using DLL build of wxWidgets.
* If using MSVC 7 only (i.e. not for later versions), also define
wxUSE_RC_MANIFEST=1 and WX_CPU_X86.
* Add $WXWIN\lib\prefix_lib-or-dll to the libraries path. The prefix depends
on the compiler, by default it is "vc" for MSVC, "gcc" for g++ and so on.
* Add the list of libraries to link with to the linker input. The exact list
depends on which libraries you use and whether you built wxWidgets in
monolithic or default multlib mode and basically should include all the
relevant libraries from the directory above, e.g. "wxmsw30ud_core.lib
wxbase30ud.lib wxtiffd.lib wxjpegd.lib wxpngd.lib wxzlibd.lib wxregexud.lib
wxexpatd.lib" for a debug build of an application using the core library only
(all wxWidgets applications use the base library).


Microsoft Visual C++ users can simplify the linker setup by prepending
"$(WXWIN)\include\msvc" to the include path (it must come before the
"$(WXWIN)\include" part!) and omitting the last step: the required libraries
will be linked in automatically using the "#pragma comment(lib)" feature of
this compiler.

Just generate an empty windows application with MSVC wizard and follow the bolded instructions. Should take less than 5 minutes.

[vcf]

Hello PB,

thanks - yep, seems fine, similar to my old VS6 ..

Unfortunately I'm stuck in the community version of VS2015 where I cannot access the
directories paths out of whatever reason (view-properties window - cannot do anything there)
etc.

Maybe I should try to reinstall VS6 ....

Nevertheles thanks a lot - Regards - Volker

[PB]

While I use the VS 2015 Express, I have played with MSVC 2017 Community and it is pretty much the same - I doubt it is issue with it. If the paths etc are not displayed in he properties, it is usually because you do not have a project selected in the Solution Explorer window but you have selected either the whole solution or an individual file.

While I liked MSVS6 back then, it's not 20th century anymore so avoid it, just like you should avoid wxWidgets older than 3.x.

[vcf]

Hi all,
Hi PB,

worked the afternoon on dealing with MSVC2015 and WxW 3.0.3

Some strange things as follow:

1. WxW 3.0.3 builds fine (24 files without any error - releas, dynamic libs,
lib_vc and ~\mswu exist)
2. Followed all the points you, PB, pointed out [ $(WXWIN)\include in compiler
and resource etc.)
3. Updated my samples, tried to build them but NO sample was built.
4. Tried to compile and build the minimal sample - without success.

$WXWIN points to the correct dir (tested in CMD: %WXWIN%
Der Befehl "D:\_02_A_PROGS\_06_CODING\_00_IDEs\_03_wx_WIDGETS\3.0.3_exe" ist entweder falsch geschrieben oder
konnte nicht gefunden werden // thus correctly resolved).

Get unresolved externals meaning IMHO the compiled WxW routines
haven't been found.

STH alike never happened in earlier versions of WXW with MSVC.
That is waht I meant yesterday ... No idea why and no glue where to look for ((

Any hint appreciated.

Thanks a lot - Regards - Volker

Error snippets:
==============
...............
1>minimal.obj : error LNK2001: unresolved external symbol "class wxPoint const wxDefaultPosition" (?wxDefaultPosition@@3VwxPoint@@B)
1>minimal.obj : error LNK2001: unresolved external symbol "protected: static class wxAppConsole * wxAppConsoleBase::ms_appInstance" (?ms_appInstance@wxAppConsoleBase@@1PAVwxAppConsole@@A)
1>minimal.obj : error LNK2001: unresolved external symbol "char const * const wxFrameNameStr" (?wxFrameNameStr@@3QBDB)
1>minimal.obj : error LNK2001: unresolved external symbol "char const * const wxStatusLineNameStr" (?wxStatusLineNameStr@@3QBDB)
1>vc_mswu\minimal.exe : fatal error LNK1120: 319 unresolved externals

Below the compiler, linker and resource compiler options I gathered from MSVC.


COMPILER OPTIONS:
==================
/GS /analyze- /W4 /Zc:wchar_t /I"D:\_02_A_PROGS\_06_CODING\_00_IDEs\_03_wx_WIDGETS\3.0.3_exe\include\msvc\D:\_02_A_PROGS\_06_CODING\_00_IDEs\_03_wx_WIDGETS\3.0.3_exe\lib\vc_lib\mswu" /I"D:\_02_A_PROGS\_06_CODING\_00_IDEs\_03_wx_WIDGETS\3.0.3_exe\include" /I"." /I"D:\_02_A_PROGS\_06_CODING\_00_IDEs\_03_wx_WIDGETS\3.0.3_exe\samples" /Zi /Gm- /O2 /Fd"vc_mswu\minimal.pdb" /Zc:inline /fp:precise /D "WIN32" /D "_CRT_SECURE_NO_DEPRECATE=1" /D "_CRT_NON_CONFORMING_SWPRINTFS=1" /D "_SCL_SECURE_NO_WARNINGS=1" /D "__WXMSW__" /D "NDEBUG" /D "_UNICODE" /D "_WINDOWS" /D "NOPCH" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /GR /Gd /Oy- /MD /Fa"vc_mswu\minimal\" /EHsc /nologo /Fo"vc_mswu\minimal\" /Fp"vc_mswu\minimal\minimal.pch"

Additional:
/MP

LINKER OPTIONS:
===============
/OUT:"vc_mswu\minimal.exe" /MANIFEST /NXCOMPAT /PDB:"vc_mswu\minimal.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG /MACHINE:X86 /OPT:REF /SAFESEH /INCREMENTAL:NO /PGD:"vc_mswu\minimal.pgd" /SUBSYSTEM:WINDOWS /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"vc_mswu\minimal\minimal.exe.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1

RESOURCES OPTIONS:
==================
/I"D:\_02_A_PROGS\_06_CODING\_00_IDEs\_03_wx_WIDGETS\3.0.3_exe\lib\vc_lib\mswu" /I"D:\_02_A_PROGS\_06_CODING\_00_IDEs\_03_wx_WIDGETS\3.0.3_exe\include" /I"." /I"D:\_02_A_PROGS\_06_CODING\_00_IDEs\_03_wx_WIDGETS\3.0.3_exe\samples" /D "_CRT_SECURE_NO_DEPRECATE=1" /D "_CRT_NON_CONFORMING_SWPRINTFS=1" /D "_SCL_SECURE_NO_WARNINGS=1" /D "__WXMSW__" /D "NDEBUG" /D "_UNICODE" /D "_WINDOWS" /D "NOPCH" /D "UNICODE" /l 0x0409 /nologo /fo"vc_mswu\minimal\%(Filename).res"

[doublemax]

The "3.0.3_exe" in several places in the paths looks wrong. Double check your settings.

[vcf]

Hi Doublemax,

only kind of personal spleen - means nothing but my place where I
stored the WxW files (was replaced bcs my WXWIN points to this dir).

Maybe file names too long?!?

Thanks a lot - Regards - Volker

[PB]

Some strange things as follow:

1. WxW 3.0.3 builds fine (24 files without any error - releas, dynamic libs,
lib_vc and ~\mswu exist)

This is strange, if you built dynamic libs using the default settings, these should sit in WXWIN/lib/vc_dll. Additionally, I see "vc_mswu" paths, the dll build should refer to "vc_mswudll"... Are you sure you actually built the DLL (aka shared) build?

I created simple MSVC 2015 solution for an application using wxWidgets. It contains static Debug and Release configurations for 32- and 64-bit buids, see the attachment and assumes the user did not customize the wxWidgets build.

If one wants to use this project then aside from WXWIN variable to be properly set, one needs to select the configuration(s) that were actually built. If the DLL build of wxWidgets is to be used instead of static one, one needs to change "vc_lib" to "vc_dll" in Linker/General/Additional include directors and add WXUSINGDLL to preprocessor defines...

[vcf]

Hi Doublemax,
Hi all,

your argue about the broken file name bcz of ....\3.0.3_exe dir name
was absolutely correct ....

Placed WXW in a directory called D:\wxw303 and minimal compiled and built
without any complains.

Of the 97 files in the sample 94 compiled fine - the rest is naught.

Thought the long name with the two dots wouldn't be a hurdle
but it is ((

Okay, seems to be a name convention problem in WxW - as less as it likes
blank spaces it likes the long filenames.

Anyone who maybe knows details about filename conventions in WxW?!!

Doesn't matter. - SOLVED - Thanks to all!

Have a good time all!!!

[doublemax]

I'm almost certain this has nothing to do with wx. It's more likely a Windows or VS issue.

[vcf]

Hi all,
Hi PB, Hi Doublemax,

thnx for your help and comments.

@Doublemax:

I will try to trap down the name conventions the next days and will
come back with results.

@PB:

Thnx for the code and thnx for the analysis of my options and error snippets,
unfortunately I haven't seen your post out of I don't know why reason when
I answered before.

For sure I din't build dynamic but static libs - sorry - the last days were hard
and I'm somehow done ...

Today I have no time to care for the matter and thus to test your code
but I will try to do over weekend.

Where and how exactly to place the WXUSINGDLL in case I would try to test
it? (somewhat __WXUSINGDLL__ or -WXUSNGDLL or alike?)

@ALL:

Are there any methods to control and/or trap down the actual COMPILER(S)' and
LINKER's search paths while executing a code?!?

Once more thanks a lot.

Have all a nice weekend - Regards - Volker

[PB]

Where and how exactly to place the WXUSINGDLL in case I would try to test it? (somewhat __WXUSINGDLL__ or -WXUSNGDLL or alike?)

If you are not using dynamic (DLL) build then you do NOT define WXUSINGDLL. Please notice that exact spelling matters here. IF you do use a dynamic build, you add it to the preprocessor definitions in C++/Preprocessor, i.e., the same place where you added e.g. __WXMSW__ .

Are there any methods to control and/or trap down the actual COMPILER(S)' and LINKER's search paths while executing a code?!?

None I am aware of, as such thing seems rather useless. If you want to see what the actual paths are when using system environment variable in the IDE, click the combo box arrow at the end of the line with those definitions, choose Edit... and in the dialog that pops up you can see the evaluated values.

[vcf]

Hi all,
Hi PB,

first of all again thanks a lot for your answers.

Definitely I was wrong when I assumed there would be any name
convention probs in WxW (too many _ , . , - etc.) and there also
don't seem to be some in the LINKER nor in MSVC.

@PB:

Thanks for the example file - succeeded to build it in a dir outside
my WXWIN variable path as DEBUG X86 and quiet sure I will also
as RELEASE X86 in case I will change my WXWIN dir name accordingly
to my RELEASE build dir.

Will try to work on the differences between your project variables and
options and the one that were created when MSVC updated an untouched
and clean copy of the minimal project that have in a dir outside my
WXWIN dir path (gives ne wx/prec.h file not found).

How do you organize the different version builds? All in the same dir (thus
all the mswu and mswud and also the appropriate X64 dirs in the build
subdir?) or do you have different dirs for the DEBUG/RELEASE and the
X86/X64 versions of the build (as I started a separated X86 DEBUG and
RELEASE?

Thanks a lot once more Regards - Volker

[coderrc]

COMPILER OPTIONS:
==================
/GS /analyze- /W4 /Zc:wchar_t /I"D:\_02_A_PROGS\_06_CODING\_00_IDEs\_03_wx_WIDGETS\3.0.3_exe\include\msvc\D:\_02_A_PROGS\_06_CODING\_00_IDEs\_03_wx_WIDGETS\3.0.3_exe\lib\vc_lib\mswu"

just want to point out that D:\foo\D:\bar is never going to be a valid path. perhaps you forgot a path separator?

[PB]

Thanks for the example file - succeeded to build it in a dir outside
my WXWIN variable path as DEBUG X86 and quiet sure I will also
as RELEASE X86 in case I will change my WXWIN dir name accordingly
to my RELEASE build dir.

If you built wxWidgets with MSVC using a provided makefile or MSVS solution, both debug and release libraries are (assuming you built them) in the same folder, e.g., WXWIN/lib/vc_lib. The debug versions of libraries have an extra d in their name, e.g., wxbase31u.lib vs wxbase31ud.lib.

If you put $(WXWIN)/include/msvc at the first place in the C++/General/Additional Include Directories as I did in the project I attached in my previous post, i.e., the libraries are linked automatically, the debug or release version gets picked based on whether _DEBUG is defined in C++/Preprocessor/Preprocessor Definitions.