I decided to seriously go into making my reports into PDF instead of using 3rd party tools.
The demo runs perfectly.
Once i use the inc in my own program i get an error.
See the attached screepclip.
This is something i really want to master and use.
What is the link to the PDF source code, or can you attach it to your post so I can try it.
http://www.planetsquires.com/protect/forum/index.php?action=dlattach;topic=3547.0;attach=1698 (http://www.planetsquires.com/protect/forum/index.php?action=dlattach;topic=3547.0;attach=1698)
What is weird, is that if i start a new project and add this .inc it runs just fine.
I have already managed to make a simple Pdf .
But the moment i add this to my big project i immediately get this error on startup.
Instead of putting the cPDF.inc into your project as a Module, try adding it to FF_AppStart as an #INCLUDE
Say, for example...
#Include "cPDF.inc"
See if FF complains. It probably won't because FF does not parse #Include files whereas it will parse Modules and attempt to regroup TYPE's, MACROS, etc in order to help with forward referencing.
BTW, that cPDF code is pretty awesome. Rick did a great job there.
The error message clearly indicates the cause: it is trying to replace the pi parameter with the value 3.14....
In cPDF.inc there is a macro:
Macro PI = 3.141592653589793##
that is causing the error.
I have said a LOT of times (and I mean a LOT) that the use of macros for this purpose is a can of worms. You define Macro PI and nobody else can use PI for any purpose.
Change the name for another that does not cause a conflict.
Doh! Of course! How did I not spot that in the error message. The macro is named the same as the parameter of the function. Sometimes I can't see the forest for the trees.
This is not helping.
As soon as i change the macro, its just the next thing again...
I think its best if i either redesign the old project, or create a workaround exe.
If i add it unchanged to a new project there is no error.
Perhaps too many duplicated string & function names in an old project.
I would think that if you changed the Macro to be an equate that it would work? Wouldn't it? Equates should not interfere with sub/function parameter naming.
PowerBASIC equates don't work with float numbers. Anyway, we don't know what that "next thing again" is...
No worries.
As soon as i changed the Macro, there is another error....and another.
Just because some of the old projects functions happen to have the exact names.
This does give the reason to stop procrastinating and redesign a project i should have done years ago.
Laaaazy..... ::)
Do it better the next time with all the new stuff i have learned from you guys, it can only get better!!
Quote from: Jose Roca on February 28, 2017, 03:06:02 PM
PowerBASIC equates don't work with float numbers.
That'll be the perfect place for a (
class full of multiple float numbers each exposed as a) readonly property ...
One should not under-estimate the speed of Powerbasic combined with this class from Richard.
I have been designing a customer form to replicate the manual one used by the organisation.
It will fill data from my database on request and leave space for the customer to make changes on information.
It is quite an undertaking drawing a "million" blocks. I assume the original organisational one was drawn in Excel given the thousands of little blocks they had in there.
What is amazing, is how extremely fast this draws, and i can promise you, i have quite a number of blocks and loops in here already.
(Still a mile to go though!!)
LOL and it also reminded me why i preferred tools like Firefly for programming and PFD makers instead of going the long route...
This method called from my program designs and fills the data about 10 times faster than my previous method using Excel Macros.
Great stuff.
Sorry about that macro. I had changed my copy of the code to wrap it in a function cmPI.
Rick Kelly