PB/CC + PB/Win + Contools/GFX - how to, please!

[Daniel Raymer]

Probably Eric is the keeper of this knowledge, but I'll take any help I can get....

I'm porting my 30,000 line aircraft design code from PB/DOS to Windows, using PB/CC with Contools/GFX. So far, so good, and thanks to all who are answering my stupid questions and posting good stuff to use.

I'm using PB/CC with Contools/GFX as the main framework, but am worried that when I get the full 30,000 lines of code ported over, I may exceed compiler limits, run into weird stuff, etc... I can break out a lot of the calculation parts of the code and would like to compile them separately as DLL's, and have bought PB/Win for that purpose. However, I really have no idea how to do it and am hoping someone can post a "framework" telling me (1) how to code, compile, and independently test the DLL's in PB/Win, and (2) how to call them from PB/CC.

When calling DLL's from PB/CC I'd want to pass a lot of data TO the DLL (perhaps 100 double precision numbers and 20 strings) then pass a similar amount back to PB/CC, and also write lots of stuff to output text files. A single DLL might be a thousand or so lines of engineering calculation code, and I'll probably have a few dozen of them. I probably won't have any GUI i/o in the DLL's, just number crunching.

Or, maybe PB/CC can easily handle such a large program, or maybe there is another better way of doing this. I am only an egg.....

Thanks in advance !

[Michael Mattias]

Only 30,000 lines of source code won't cause either the PB/CC or PB/Win compilers to even breathe hard.

As far as your 'passing' data to a DLL...

You are limited to 32 parameters per function. However, given your description - .
" perhaps 100 double precision numbers and 20 strings" - it can be done with two parameters...

FUNCTION MyFunction (d () AS DOUBLE, S() AS STRING) EXPORT AS LONG

END FUNCTION

.. and because those arrays are passed by reference, you can modify them in your function and the calling function will be able to read the modified data just fine.

You use functions in a DLL the same as a function you write in your main module, exactly the same.

However, you need to EXPORT a function in your DLL to make it visible to other modules, and in the using modules you need to DECLARE those functions with a LIB clause.

That's all there is to it.

MCM

[Michael Mattias]

Um, I forgot some things it sounds like you may not be aware of...

• Variables cannot be shared by name across modules.. eg a GLOBAL variable is global only to its own mpdule. There is no equivalent to the PUBLIC and EXTERNAL clauses used to share data across modules in PB/DOS.
• PB File handles are only valid within the module in which they are obtained. There is a simple way to share a handle across modules, but let's hold off on that for now.
• DDT commands using a dialog handle or are only valid within the module in which the dialog was created.
• A thread function must reside in the same module as its associated THREAD CREATE statement.

[Elias Montoya]

For the 100 variables, Michael is right, number of parameters is limited,
but you can do this:

TYPE My100Variables
 Var001 AS DOUBLE   
 Var002 AS DOUBLE   
 Var003 AS DOUBLE   
 Var004 AS DOUBLE   
 Var005 AS DOUBLE   
 .
 .
 .
 Etc...
END TYPE

FUNCTION FunctionToCall(MyVariables as MY100Variables, String1 as String, String2 as STRING... Etc... ) AS (YOUR CHOICE)

' Your Code Here

END FUNCTION