XPorter and migration - complicated situation

[wriedmann]

Hi Chris,
please let me explain first one important thing how I'm working in VO.
Very often I have to share code between different applications, mostly between a GUI program and a Windows service, and I am doing this using external files that are used by more than one application in VO.

Now, I have started to combine applications that are running as VO applications and others that are running as X# applications.
Therefore I have the need to share prg files between VO and X# applications.
This works very well using even when X# needs "end class" statements that are not understand by VO:

Code: Select all

class CreateUpdateStatement inherit CreateStatement
method GetSQLString() class CreateUpdateStatement
local cStmt as string
local nLen as dword
local nI as dword

cStmt := ParmSubst( "update %1 set ", _cTableName ) + " "
nLen := ALen( _aFields )
for nI := 1 upto nLen - 1
  cStmt += ParmSubst( "%1 = %2, ", _aFields[nI,1], self:FGStringSQL( _aFields[nI,2] ) )
next
cStmt += ParmSubst( "%1 = %2 ", _aFields[nLen,1], self:FGStringSQL( _aFields[nLen,2] ) )

	return cStmt

method Init( cTableName ) class CreateUpdateStatement

	super:Init( cTableName )

	return self

#ifdef __XSHARP__
end class
#endif

Now the problems arises when I have to migrate VO applications that use these external files because XPorter adds a supplemental "end class" statement.

Do you have any idea how I could solve that?

Personally I could see several possibilities:
- XPorter recnognizes the end class that is present in the conditional compilation and does not creates a new one
- XPorter recognizes that the module is an external module in VO and optionally takes it "as is" and does nothing
- I could add some statement/comment for XPorter in the module so it leaves it "as is" without changing anything

Or maybe you have a better suggestion....

This is really in issue in migration because I'm doing that massively. The module where the sample code is taken is used by at least 10 different applications, and some of them are already in production in their X# version.

Wolfgang

[FFF]

Happy Easter! You shouldn't work now
I'd think the easiest way should be, to teach the exporter checking for end class instead of unconditionally add the phrase.

[wriedmann]

Hi Karl,
happy easter to you too!
In theory, my wife and me should be on holiday for the next two weeks, but we had to cancel that because of issues at work.
Wolfgang

[Chris]

Hi Wolfgang,

The VOXporter has an option (enabled by default) that ignores code inside #ifdef statements, so that do the trick already. Maybe you are using an old version that did not support this? If yes and do not want to install a recent X# version, I can send you a recent version of VOXporter only.

If for any reason this does not work well for you, will look into the other options you mentioned, one of those could be a good alternative, too.

ps. Happy Easter to all!

[wriedmann]

Hi Chris,
Happy Easter to you also!
Regarding the VO XPorter: I'm using the current beta of X#, and this option is checked.
My problem is not that the VO XPorter touches the code inside the ifdef, but adds a second end class statement.
Wolfgang

[Chris]

Hi Wolfgang,

Ah, right, I thought this option completely removes the code inside #ifdef, but indeed it only just does not modify it.

One thing you could do is to add a "{VOXP:DEL}" tag in a comment after the END CLASS line inside your #ifdef, so that VOXporter removes this and only one exists after the port, the one that VOXporter adds manually.

But I think the best way you should prefer it to work is that VOXporter does not touch at all the code of the module/file, so it does not make any other changes either to it. For this I could add a special tag that you'd need to put in the first line of the file and tell VOXporter to not touch it at all. Only issue with that is that it would still need to parse it, so some features like finding callback function still work. Will look into this closer and will get back to you.

[wriedmann]

Hi Chris,
thank you very much!
For the moment I will use the {VOXP:DEL} tag to solve that issue, but a possibility to ignore the file (or better: to not change it) would be very helpful.
Wolfgang
P.S. maybe I overlooked it: but is there some list of all available tags?

[FFF]

Maybe I miss the obvious, but again:
imho the exporter reads the source file, finds a class definition, steps ahead until the next entity definition and adds at the end the end class statement. Where's the problem, the consider the last line, if there's a "end class"and if so skip?
Edit: finally scrolled on the mobile far down enough to notice Wolfgang framed the end class with the "if def", so I see the problem, sorry.

[wriedmann]

Hi Karl,
the issue is that the same source code is used in 3 different ways:
- directly by a VO application as external file
- directly by a X# application as external file
- migrated by XPorter to an X# application
For the first two cases I have already a solution with conditional compilation as shown in my code, and for the 3rd Chris has proposed a viable alternative.
I have to say that the X# team has done a very great work because otherwise it would not be possible to use the same codefile both in a VO and a X# application.
Wolfgang

[Chris]

Hi Wolfgang,

I had included those in my conference material for the port from VO session in Memmingen, but you are right there should be a section in the help file about them. In short:

{VOXP:COM} : Comment current line
{VOXP:UNC} : Uncomment
{VOXP:DEL} : Delete line