product information in converted VO application

leighproman · Post by **leighproman** » Wed Jun 12, 2019 4:02 pm

Redacted version of version.rc attached.
Thanks
Leigh

Chris · Post by **Chris** » Wed Jun 12, 2019 5:08 pm

Hi Leigh,

Hmm, not sure why, but indeed this doesn't work, until I add this in the beginning of the .rc file:

#define VS_VERSION_INFO 1

This should fix the problem for you, will try to find out why this happens...

leighproman · Post by **leighproman** » Wed Jun 12, 2019 5:23 pm

Thanks Chris - that's working for me now.
Leigh

Chris · Post by **Chris** » Wed Jun 12, 2019 5:32 pm

Thanks for the feedback Leigh! Still puzzled why it silently does not work properly without it...

robert · Post by **robert** » Wed Jun 12, 2019 5:52 pm

Chris,
The versioninfo resource MUST have resource type 1. In VO the define VS_VERSION_INFO is automatically replaced with 1 because VO finds it in the Win32 API library, even when this library is not included in the libs of the App. (yes that is weird, but that is how the original VO developers designed things).

If your app does not have any native resources (rc files) then the X# compiler creates a version info resource based on the information in the AssemblyVersion, AssemblyFileVersion etc attributes

Robert

Chris · Post by **Chris** » Thu Jun 13, 2019 2:31 am

Robert,

What I was puzzled about, is what the resource compiler substitutes "VS_VERSION_INFO" info with, when you do not specify the define. Apparently it substitutes it with nothing, VS_VERSION_INFO is inserted as a string in this case.

Strange thing though is that if you do not specify "VS_VERSION_INFO" at all in the .rc file, but use the value 1 directly, then the string "VS_VERSION_INFO" does still appear embedded in the compiled resource!!! Looks to me like some weird hack MS has done here...

Karl-Heinz · Post by **Karl-Heinz** » Thu Jun 13, 2019 7:10 am

Hi Chris,

the resource compiler is a special beast. It doesn´t complain when i change e.g. a created manifest.rc content from :

1 24 Resourcescctl6.man

To e.g.:

GAGA1 GAGA2 Resourcescctl6.man

Of course, this works

#define GAGA1 1
#define GAGA2 24

GAGA1 GAGA2 Resourcescctl6.man

BTW. It´s no showstopper, but i noticed that a newer XPorter version exports something like:

xyz ( NULL )

to:

xyz ( @@NULL )

which results in the error: "The name 'NULL' does not exist in the current context".

.
regards
Karl-Heinz

Chris · Post by **Chris** » Thu Jun 13, 2019 2:09 pm

Hi Karl-Heinz,

Thanks, this has been fixed already in the VOXporter for the next build (tomorrow probably).

About the resource compiler, yeah it is really bizarre how it works some times. Btw, try saving a .rc file in unicode format, compile, see the errors it produces and try to figure out what the problem is by the error messages...

Karl-Heinz · Post by **Karl-Heinz** » Fri Jun 14, 2019 5:56 pm

Hi Chris,

have you tried in the meantime to find out why the XPorter doesn't export the version info ? If not, add a leading char ( e.g. "_" ) to "VS_VERSION_INFO", so that the VO Resource line looks like:

RESOURCE _VS_VERSION_INFO VERSIONINFO

instead of:

RESOURCE VS_VERSION_INFO VERSIONINFO

Now the XPorter creates a resource file, and when i change in the rc file the line

_VS_VERSION_INFO VERSIONINFO

to:

1 VERSIONINFO

or:

#define VS_VERSION_INFO 1
VS_VERSION_INFO VERSIONINFO

the version infos are visible.

regards
Karl-Heinz

Chris · Post by **Chris** » Fri Jun 14, 2019 6:59 pm

Hi Karl-Heinz,

Yeah, I had totally forgotten about it, but had actually added explicit code to not port this resource, because of problems with some of the defines (not only VS_VERSION_INFO). Will enable it back, not sure if this will make it in this or the next build though.

Main menu