The saga continue. I am finally putting my nose to the grindstone and migrating to C11.1. (a big jump, I know).
I have compared templates from our C5 (with DET) environment and managed to pluck out the differences which I think I have mostly merged into the C11 templates (refer to previous messages regarding a previous programmer who modified the DET and CW templates).
I have exported the first application to TXA, made some changes I identified were necessary (some, perhaps not all) and imported the txa into a new app in C11.
I am now troubleshooting some errors when building said application.
The application uses some (many) windows API and C calls and is complaining of ‘Unknown function label’ for example for GetLastError(), strlen() however if I ‘Include(‘cwutil.clw’)’ or ‘include(‘clib.clw’)’ with or without a ONCE, I generate a HUGE number of errors.
I’m struggling to figure out where I’m going wrong, or what I have overlooked.
I know it’s difficult to diagnose without having the app, I may not have explained it very well either, but hoping someone may have had a similar experience and can point me in the right direction.
As a side note, what is a ‘solution’ in C11? Is it the same as a ‘project’ in C5? Is it just a change of name or something deeper?
A solution is something new (in Clarion 7). Think of it as a “batch compiler”. It is a collection of one or more projects (cwproj files) which in turn means it’s a collection of 0, 1 or more app files.
A cwproj is loosely the same as a PRJ file in Clarion 5. (In C5 the APP contained an internal PRJ section, so apps didn’t have an external PRJ. In C7+ the PRJ is external to the app, and named .cwproj)
All apps have a cwproj file (external). However what the app opens is a “solution” (sln) file. As a courtesy if you open an app, or cwproj, then it actually opens the SLN for you. If a SLN does not exist one is created.
What’s nice (really nice) about the SLN (solution) is that it can contain multiple apps, and multiple cwproj files. So if you “generate a solution” or “build a solution” you’re doing all the apps at once.
This means the function does not exist in the MAP anywhere. It’s likely that your C5 project had some include, or template change, that included these extra functions in the MAP. Search your C5 system to see how these got added to the MAP. In C11 you likely want to add them via an Include file, or as embed code. do not edit the shipping templates.
Search your C5 files for “GetLastError” and you should find a source file (probably .CLW or .INC) that contains a line like one of the below. The NAME('GetLastError') may not be present.
GetLastError(),LONG,PASCAL,NAME('GetLastError') !Indented (not column 1) format
GetLastError PROCEDURE(),LONG,PASCAL,NAME('GetLastError') !Column 1 "Procedure" Format
GetLastError FUNCTION(),LONG,PASCAL,NAME('GetLastError') !Column 1 "Function" Format
This file may not be in your Project folder, it may be in a C5 folder (LibSrc, 3rdParty\LibSrc) so it can be shared by all Projects using the RED file. Look at the RED as there may be other files included.
It took me some time but I did figure it out, eventually.
We have some include files which were created (probably from a C6 install) which contain similar equates and function prototypes to several include files in C11. I had to comment out chunks of these equates and prototypes (from our include files) to as to eliminate duplicates and then I had to include one or two of the C11 includes (which I had failed to do previously).
There were also some duplicate function names in our app. AFAICT they had a different prototype but C11 still complained about them. I renamed them (and their calls) and managed to get a DLL built.
Anything I find duplicated in our source files I’m tending to undo in deference to using the C11 files.
On to the next app.
Thanks for the tip on solutions too, I can see that being mighty helpful when building - our application has 49 app files and setting a solution off for a build will be a time-saver compared to C5.
It seems to be targetting just this line. Other lines in the same app that include a ‘<’ aren’t being reported as an error. In fact, many strings (with SQL statements) that contain a single ‘<’ aren’t being reported in error, though some of those are <= or <>. Examples:
Clarion uses < Less-Than / Greater-Than > in strings to encode CHR( Ascii ) e.g. <13,10> for CR+LF.
To use a Less-Than as a < character it should be doubled so <<> 0 or << 30000. Same for Open Curly Brace {{ since Clarion uses that to encode repeat count.
As Sean said the compiler has recently stopped automatically figuring out a single < in text. I think when 11.1.13788 release added PRAGMA ('option(eol_is_space => on | off)')
FEATURE: Added a new pragma to support multi-line string literals; PRAGMA option(eol_is_space => ON/OFF) : if the pragma is ON, end-of-line characters inside
a string literal are treated as whitespaces allowing string literals to be multi-line. There are two requirements, the last line of the
assignment statement must be terminated with a semi-colon, and you cannot have a WINDOW,REPORT,FILE or VIEW defined within the source code
where the pragma is ON.
The Open(Report) did not error so it appears the REPORT is valid.
I would suspect the PrintPreviewImage queue is not defined, or is a TYPE. The red underlined code is not always the exact problem code.
I would add some lines using that Queue to see if they error:
Open(Report)
X# = PROP:Preview !Test if PROP:Preview compiles OK, a PROP: its just a Long so can assign X#=
X# = RECORDS(PrintPreviewImage) !Test if Queue compiles OK
GET(PrintPreviewImage,1) !Test if Queue compiles OK
Report{PROP:Text} = 'Test' !Test a simpler Prop: for Report compiles
Report{PROP:Preview} = PrintPreviewImage
I’d move the SECTION() to Column 2. I’ve seen that code in Column 1 have problems with Omit/Compile.
if you want to keep the code to be useful in c5 and c11, you can use instead of double less-than an ascii code, so you can write ''X < 3000" like “X <60> 3000” … c5 will compile without a problem, like c11 too. bigger-than will not be a problem in c11
The doubled << and {{ work in all versions of Clarion including DOS.
So that << 30000 code will work in C5 and C11. During conversion I often go back and fix problem in the old version … figuring it may take a few tries.