Icon statement truncated while compiling, on hyphen

[ic2]

I've decided to Xport my main general library, just to see how much comes up. The only (now visible) error is:


Error RC2135 file not found: c:Voprgiconscomment IC2 lib C:XporterOutputIC2 libIcons.COMMENTADD.rc 1

Code: COMMENTADD Icon c:Voprgiconscomment-add.ico

As you can see the code gives the (existing) icon name comment-add.ico but the file not found error only uses the name unti lthe hyphen.

Is this a known issue?

Dick

[Chris]

Hi Dick,

No, not known, but I suspect it's the hyphen being translated by the resource compiler tool as a command or something like that. Please open the .rc file and put double quotes (") around the icon filename. Does that fix it?

Chris

[ic2]

Replying on #2:

Hello Chris,

Yes, that fixed it, thanks. So either the resource compiler should do something different with a hyphen, or XPorter should add those quotes by default I'd say? The other errors (next issue) remain so I'll send you the code.

Dick

[Chris]

Hi Dick,

Yeah, most probably this will be the fix to that problem. We were just not aware of such a potential problem before you reported this

Chris

[ic2]

Reacting on #4:

Hello Chris,

We were just not aware of such a potential problem before you reported this

Leave it to me to find problems like that .

Hopefully the File not found problem in the other resources is something small too (I sent you the AEF).

DIck

[robert]

Dick,

Replying on #2:
Yes, that fixed it, thanks. So either the resource compiler should do something different with a hyphen, or XPorter should add those quotes by default I'd say? The other errors (next issue) remain so I'll send you the code.

I reviews what VO is doing, and it does A LOT when compiling resources:
- it writes each resource from the repository into an external file
- it replaces macros in filenames like %cavodir% and %cavosamplesdor% with the actual valies
- it looks up all tokens in the resources, like IDI_STANDARDICON and replaces them with the values of DEFINES when they exist in the repository (in the standard app IDI_STANDARDICON will be replaced with its value 101)
- for file based resources (like icons) it puts double quotes around filenames when necessary
- it even replaces all backslashes with a double backslash

In VO all resources are compiled individually and the linker links these together into the EXE or DLL.
In Dotnet assemblies we can only link one combined native resource. So we either have to individually compile the RC files and "glue" the result together or we combine all the RC files into one RC files and compile the combined resource file, or (what we are doing right now) is to create one RC file with #include statements for the original RC files. The advantage of that approach is that when there is a problem at least the resource compiler will point to the right location.

I think the best approach for us is to update the RC files when we are exporting them from the AEF.
Adjusting the RC files at compile time will only work if we create a copy of the RC file, but then an error message from the Resource COmpiler will point to the (changed) copy of the RC file and not to the RC file in your VS solution.

Robert

[wriedmann]

Hi Robert,

PMFJI,

the VO solution has a big advantage: it can handle replacements and variables. It would be a very welcome thing if defines could also work in ressource statements like the VersionInfo ressource.
For VO this was a needed step as all the source was contained in the repo, but I would also opt for a similar thing in X#.

Wolfgang

[robert]

Wolfgang,
It will be very difficult to do it the way VO does it, at least without sacrificing performance.

The build process in VS is based on MsBuild and actually runs outside of VS. At the time that the build process compiles the resource items (these are represented with items of type NativeResource in the XSPRoj file) then MsBuild calls a special task special task "NativeResourceCompiler " inside XSharp.Build.DLL "knows" how to create a file NativeResources.Res from the RC files. This task checks for the existence of this file and compares its timestamp with the timestamps of the RC files in the project.

Lets assume you are building MyApp.DLL. Then the task inside XSharp.Build.DLL in theory could read the list of dependencies for MyApp.DLL and use reflection to read all the defines in these and find the defines (constants) in these DLLs and do a search and replace on the RC files. Of course we would not want to change the original file, so we would have to create copies of all RC files introducing the problem that I mentioned in my reply to Dick: error messages from the resource compiler will no longer point to the original files.

But even is that acceptable, there is a second problem:
For the source from MyApp.DLL there is no DLL to reflect (because that DLL is being built) or an older copy of the DLL.
To find all the DEFINES in this source the NativeResourceCompiler task therefore would have to read all source files in the project and extract the info for the defines.
In VO this is not an issue because at the time when the resources are compiled all the source has been parsed (not necessarily) compiled and all the info is available.

The only thing that I can think of at this moment is that the VS project system would write all the defines for a project into a separate file which could be read by the NativeResourceCompiler task. However that would not work on Build Servers, because on these machines there is NO VS running.
And of course the problem remains that the error messages will point to the wrong files.

To help solve the problem we have done the following for RC files that are generated by the form editor and menu editor: we do not #include a file with defines, but we write all the #defines directly in the RC files. We even write the defines for the windows styles so there is no dependency on any external file:

Code: Select all

#define DIALOG_PUSHBUTTON1 100
#define DIALOG_MULTILINEEDIT1 101
#define DS_3DLOOK 0x00000004
#define DS_MODALFRAME 0x00000080
#define ES_AUTOHSCROLL 0x00000080
#define ES_AUTOVSCROLL 0x00000040
// etc

MySuperDialog DIALOGEX 3, 3, 265, 146
STYLE DS_3DLOOK|WS_POPUP|WS_CAPTION|WS_SYSMENU|DS_MODALFRAME
CAPTION "Designed Dialog"
FONT 8, "MS Shell Dlg"
BEGIN
	CONTROL "Close", DIALOG_PUSHBUTTON1, "BUTTON", WS_CHILD|WS_TABSTOP, 155, 109, 66, 20
	CONTROL "", DIALOG_MULTILINEEDIT1, "EDIT", WS_CHILD|ES_MULTILINE|WS_TABSTOP|WS_BORDER|ES_AUTOVSCROLL|ES_AUTOHSCROLL|ES_WANTRETURN, 13, 9, 221, 86, WS_EX_CLIENTEDGE
END

I think the only real problem are the RC files of type ICON, CURSOR, BITMAP and similar. They can no longer use a DEFINE for their name but need to use the correct literal.
If you can think of a smart solution that should take care of this (without sacrificing performance), then please let me know.
For versioninfo resources I would use the following approach:
- define the version numbers in a separate header file
- include that header file in your version resource
- include the same header file in the assemblyinfo.prg to set the managed version information.
We have done something like that for the versioning of GUI classes in the SDK in the Vulcan days.

Code: Select all

#include "BuildNumber.h"
VS_VERSION_INFO VERSIONINFO
 FILEVERSION FILEVERSION_NUMBER
 PRODUCTVERSION VERSION_NUMBER
 FILEFLAGSMASK 0x37L
#ifdef _DEBUG
 FILEFLAGS 0x3L // VS_FF_DEBUG + VS_FF_PRERELEASE
#else
 FILEFLAGS 0x0L // 
#endif
 FILEOS 0x00040000L
 FILETYPE 0x2
 FILESUBTYPE 0x0L
BEGIN
 .. 
 .. 
END

and inside Assemblyinfo.prg

Code: Select all

#include "BuildNumber.h"
[assembly: AssemblyVersionAttribute( VERSION_NUMBER_STR )]
[assembly: AssemblyFileVersionAttribute( FILEVERSION_NUMBER_STR )]
... etc

Robert

[wriedmann]

Hi Robert,

thank you very much for your long and detailled anwser!

I will use the approach you recommended for my VersionsInfo ressources.

Thank you again!

Wolfgang

[ic2]

Reaction on #8:

Hello Robert,

I am afraid I can't recommend how you should solve it but I have a few notes:

1 In the current exported lib I get no clue at all to where it goes wrong on compiling. Not in Xide and not in VS, although for the latter,, with detailed messaging on, I do get an error, see below. It may be because of what you write but it means I can not solve anything currently (Chris has received the solution to check).

2 On my system a Rebuild in X# and compile (after touch) in VO take 14 seconds for both, exactly the same. An additional build (e.g. when I change 1 character) takes 10.8665603 seconds in X# and less than a second in VO. VO is many times faster but I suspect this is because of the problem with this solution. Another X# project which compiled fine rebuilds in only 0,2 seconds! Compilation and build speed was an issue in early Vulcan versions but I think X# is really fast.

So I could imagine that performance is an issue when VO is more than 10 times faster but for "normal situations" X# seems to compile very fast and I think we should keep it this way. Otherwise, would it be a solution to have an option to choose between the fastest and least informative way of compiling with resources and a slower but more informative compile option to see where exactly the error is located? Like the Detailed information in VS but then as a default compile option?

I don't mind if that is something for a version 10. I was just curious if I could Xport and clean up one of our main libraries for X# use and I can not -yet. No problem at all do retry this after modification in a later version. On the other hand, it may be something specific in this library and Chris is a master in finding the most obscure causes for compiler errors so maybe he finds something which allows me to proceed. But if not, I think it is important that anyone's VO conversions will yield enough information to find and correct errors.

Dick

PS: For info: this is basically the next step; the hyphen question where this thread started with is solvable and will be addressed in future versions.

Error:

Unhandled Exception: System.AggregateException: One or more errors occurred. ---> System.InvalidCastException: Unable to cast object of type 'LanguageService.CodeAnalysis.XSharp.Syntax.InternalSyntax.BlockSyntax' to type 'LanguageService.CodeAnalysis.XSharp.Syntax.InternalSyntax.IfStatementSyntax'.
at LanguageService.CodeAnalysis.XSharp.SyntaxParser.RuleExtensions.Get[T](IXParseTree t)