C11 migration of C5 - troubleshooting Unknown Function Label

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?

Thanks,
Andrew.

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.

You want to find the file used by your C5 build.

Thanks for the replies Bruce and Carl.

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.

Andrew.

Has the behaviour with regard to include files changed in C11?

One of our include files which works fine in C5 is now throwing an error.

The include file section:
image

The error (Report{Prop:Preview}) being reported in the include file:
image

Surely it shouldn’t be validating anything in an include file until it is included in context in source?

This bit of code is included in other procedures but as source, not as an include file, and is being accepted as-is.

Also, one of our SQL strings (not all of them) is being targeted as missing a second ‘<’, not being escaped I assume:

The error:
image

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:

Were I to include a second ‘<’ to all strings would it be escaped correctly when passed?

Thanks again.
Andrew.

Not sure about the include file, but yes, the compiler started getting quite finicky about the escaped characters recently.

Thanks for the confirmation.
I’ll make sure to include that info in my migration doco.

YES.

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.

V CSTRING(1024),AUTO

  CODE
  
  PRAGMA ('option(eol_is_space => on)')
  
  V = '
        <div ng-controller="ExampleController" class="expressions">
          Expression:
          <input type="text" ng-model="expr" size="80"/>
          <button ng-click="addExp(expr)">Evaluate</button>
          <ul>
           <li ng-repeat="expr in exprs track by $index">
             [ <a href="" ng-click="removeExp($index)">X</a> ]
             <code>{{expr}}</code> => <span ng-bind="$parent.$eval(expr)"></span>
            </li>
          </ul>
       </div>

       ';
  PRAGMA ('option(eol_is_space => off)')
  MESSAGE(V)

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.