Heres my approach, I dont say its the right approach or the best approach, but its what Ive done.
I went through my code and found all the instances where the syntax to do something in PRISM is different from Delphi syntax (e.g. file manipulation: reading, writing, opening or closing a file). Ignoring syntax incompatibility for a moment, I duplicated the code segment using PRISM syntax (i.e. using all the PRISM/.NET methods that are illegal in Delphi). I incorporated a hard-coded boolean variable to act as a switch between Delphi code block and the PRISM code block.
To get rid of the PRISM-syntax errors that arise when the code is compiled in Delphi, I create dummy methods that have the same name as the .NET methods, but theyre just empty, there is virtually no code in them; they are just there to suppress compiler errors.
It doesnt matter if theyre empty because they will never be called if the software is compiled using Delphi... because of the switch mentioned above.
Then I did the same thing defining methods with Delphi names (creating a bunch of empty methods), but they are all commented out.
Result: the software compiles under Delphi and runs normally, since the PRISM code blocks are never called.
To compile for PRISM, I do the reverse; I comment out the PRISM method set (the names match up with .NET method names), and uncomment the Delphi set. The empty Delphi procedures are only there to stop PRISM compiler errors; the procedures are never called during execution, because the switch is set to select the PRISM code blocks, and the Delphi ones are never called.
It doesnt work for every problem, but does for many.
Then you can maintain two versions of your code, a Delphi one and a PRISM one, as long as you keep the dummy procedure set up to date. I wrote a white paper about this, its here: http://skyindustries.com/Page_10.0_CIED_Video.html (click on the PRISM-Delphi White Paper link at the top of the page, theres no way to attach a PDF to this comment).
--- Shawn C
|