TOPIC:

Hi Chris

thanks a lot for your explanations and your help.
I just finished the first Version of the PDF. I would be glad if you guys could have a look at it and tell me if I wrote some rubish

Have a nice Weekend
Markus

Hi Markus,

That's great!!! I didn't expect you would write this so quickly...

It is very nice because it shows that even though the process to port an app to X# is not a 10 minute job, at the same time with enough effort and after gaining some experience on it, it starts to become much easier and the end results really works. I think we probably need to create a section in the website for showing apps that have been ported to X# and for holding documents like that.

Just a small correction, in VO it is actually legal to use the syntax i = 1, when the compiler option "Old Style Assignments" is enabled. We just do not support this in X#, vulcan did not support it either.

Chris

Hi Markus,
Great to see that you had finished it!
Unfortunately in my wLib2 migration I had much more and issues, some of them also harder to explain. So it will take a week until I have finished my document.
But after seeing yours, I have decided to change the source code representation: yours is much better.
Wolfgang

Markus,
* are you interested in correction of typos, or is your plan to do final lectorate?
* i would refrain from repetitions, e.g. the "Assign must have parameter...", showing ONE sample is enough
* as the code parts are colored, you might change the color of corrected parts to make them more obvious
* the assign error in the registry access: you show the reason for the code - adding the parameter removes the error, but kills the idea

BTW, great work!

@Chris, some wishes for xporter:
* if one copies a path into the sourcefile sle and then hits the [...] the dialog starts with current dir, i.e. ignores the path input, which is a pita...
* some option to "generally" set the path for Catoxxx files would be nice
* "sometimes" the generated proj files contain images like icons, sometimes not, didn't find a rule, but might need a look
* for folks like Wolfgang, who plan to sync Vo and X# side for longer time, it would be great, if xporter could be called e.g. from Xide, _remembering settings_, so the sync could be a one click experience

Karl

Hi Karl

yes of Course, it would be very helpful.

Markus

Hi Chris

I was surprised too, when I finished the last page ...

Markus

Hi Chris

just forgot this: a separate section for These ported examples would be very helpful.
An other Thing would be a section for already ported libraries which we all uf us used for decades and in my opinion it dos not make sense that everyone does the same conversions. There might only be the Copyright stuff with the paied libraries.

Markus

Markus Lorenzi wrote: There might only be the Copyright stuff with the paied libraries.

Good idea! @Robert: couldn't we add our Vo/VN serial# to our accounts and control access to "special" download area by this? Maybe bound to Fox, possibly motivates the lurkers to subscribe <vbg>...

Karl

Markus,
Thanks for the excellent document.
A few suggestions:

• The FONT property was renamed because there is also a Font method. Dotnet does not allow a property and method with the same name. I think it is worth mentioning this because this might happen in the users code as well


• The error message about the DWORD(_CAST, LVSCW_AUTOSIZE) indicates that there is a conversion problem converting from DWORD to SHORT. I would change the code to cast to SHORT, and not to LONG, but in this case (the values are -1 and -2) there is no cast or conversion needed at all. So ListView_SetColumnWidth(...., LVSW_AUTOSIZE) should work as well and is much cleaner and easier to understand. In general in cases like this I would recommend to remove the CAST completely and only add a new one when absolutely necessary. The _CAST operator tells the compiler "I am smarter than you and I know what I am doing, so please treat the following value differently than you would normally do". In many cases people are not THAT smart.


• In your code there are GUI classes that you are subclassing because you wanted to add a method. In your small app it is not a problem to rename the classes. That is not always the case. So when you are adding a new method to an existing class (so not overwriting an existing method) I would recommend using an Extension method. Only when you need to access PROTECTED instance variables then a subclass is needed.

Finally, I think it is a great idea to add a section with ported examples. We have talked about this in the devteam as well.
I am also thinking about posting videos in which we show how apps are being converted and the changes that had to be made. The video files would be shared through Youtube with links on the website. What do you think of that?

We will also add a section for upload an download of converted libraries such as the FAB tools, RightSLE and others. Sharing converted code that has a copyright is more complicated. We are thinking about either uploading "patch" instructions or even patch files.
The problem of course is that automated patch files will only work for code of a specific version. So when you already made some changes than the patch will fail.

Robert

Karl,

I really do not want to register VO and VN serial numbers.
But maybe you are right that we should limit the access to FOX subscribers. Let me think about this and discuss it with the guys.

Robert

Hi Karl,

> if one copies a path into the sourcefile sle and then hits the [...] the dialog starts with current dir, i.e. ignores the path input, which is a pita...
>

Thanks, will fix this.


> some option to "generally" set the path for Catoxxx files would be nice

Do you mean in XIDE? Good idea to add a menu option to automatically copy CATO* dlls to the bin folder...


> for folks like Wolfgang, who plan to sync Vo and X# side for longer time, it would be great, if xporter could be called e.g. from Xide, _remembering settings_, so the sync could be a one click experience
>

Ah, forgot to add an entry in XIDE! For now you can do it by creating a file Toys.cfg in XIDE\Config folder with those contents:

MENUENTRY=VOExporter
EXECUTE=C:\Program Files (x86)\XSharp\VOXPorter\VOXporter.exe

Also agreed it would be nice to save and remember settings, will look into it. I just hate it that you can't save the current options in a cfg file in the same folder with the .exe in program files, but need to do it via registry or a cfg file in outer space..

Chris

Hi Chris,

the current xPorter version cannot be called from XIDE because the start directory is not set correctly and then xPorter does not find his configuration.

I could add such an option to my plugin, will do it when I return home.

And IMHO it would be enough to pass a configuration file on the command line, so XIDE (or a plugin) could write settings there and call them xPorter.

Currently, I'm using my plugin to copy the applications path to the clipboard and pasting it into xPorter.

Wolfgang

Hi Robert

thanks a lot for your commentes on my paper. I just built them into the paper and did also some cosmetic changes. Here is the most recent Version.
I just realized that the Excel Export in this sample does not work as expected (the app crashes).
Perheps you can see whats wrong. Just right click on the files list and choose: Liste nach Excel übertrgen.

TIA Markus
Documentation:


Project:

Hi Wolfgang,

Ah right, I haven't fixed that problem yet, thanks for reminding!

Actually I think it's a very good idea to provide also simple command line parameters to the VOXporter for the input and output, so you can call it easily externally, will do that, too.

Chris

Hi Markus,

Thanks for the updated document, getting better and better! Although I am afraid you will need to make some changes related to COM, see below. Also it would be nice to give some info why the compiler in X# requires some of the changes, but this is probably a task for the devteam In the next days/weeks I will collect the most common compiler errors reported in ported code and list them together with a small explanation and resolution, so it can be used as a reference.

Also a small comment regarding return values of ASSIGNs, those are completely ignored, because by definition in .Net an ASSIGN (Property setter) does not return a value, so you might want to change the code (remove return type from definition and return value from RETURN statement) so it reflects that.

Regarding the runtime problem with Excel, I see 2 COM-related issues:

1. The message of the runtime exception is "Types extending from COM objects should override all methods of an interface implemented by the base COM class". I searched for this error and according to

www.codeproject.com/Articles/990/Underst...roperability-With-NE

indeed you cannot simply inherit from a COM object. If you do that, then you need to provide all the members that implement the corresponding COM interface. For a very large class like Excel.ApplicationClass I think this is not feasible, so I suggest to change your IMSExcel class so it does not inherit from that class, but it uses it as a member. Of course you can do it a different way, but my solution was to change

CLASS IMSExcel INHERIT MSExcel

to

CLASS IMSExcel

and also add

PROPERTY ExcelObject AS Microsoft.Office.Interop.Excel.ApplicationClass AUTO

then added this to the constructor of the class:

SELF:ExcelObject := Microsoft.Office.Interop.Excel.ApplicationClass{}

and changed also the following:

ACCESS ExcelOK
RETURN SELF:lVisible = SELF:Visible
....
cExcelPath := SELF:Path + "\excel.exe"
...
ASSIGN Visible(lV AS LOGIC)
lVisible := lV
RETURN SELF:Visible := lV

to (just use the properties of the Excel class):

ACCESS ExcelOK
RETURN SELF:lVisible = SELF:ExcelObject:Visible
....
cExcelPath := SELF:ExcelObject:Path + "\excel.exe"
...
ASSIGN Visible(lV AS LOGIC)
lVisible := lV
RETURN SELF:ExcelObject:Visible := lV

that fixes that problem, but there's also:

2. In the _ToExcel() method, in a couple places you are assigning a VO style ARRAY to a Range object, but unfortunately the ARRAY type is X#/vulcan specific, so the COM object does not know how to translate it. Fortunately the solution is easy, you can write a function that converts a VO ARRAY to a .Net Array:

FUNCTION VOToNetArray(aVO AS ARRAY) AS System.Array
// hard coded for 2-dimension ARRAY
LOCAL aNet AS OBJECT[,]
aNet := OBJECT[,]{ALen(aVO) , ALen(aVO[1])}
FOR LOCAL i := 1 AS INT UPTO ALen(aVO)
FOR LOCAL j := 1 AS INT UPTO ALen(aVO)
anet[i,j] := aVO[i,j]
NEXT
NEXT
RETURN aNet

and then simply change

oRange:Value := aColumns
...
oRange:Value := aListe

to

oRange:Value := VOToNetArray( aColumns )
...
oRange:Value := VOToNetArray( aListe )

Now output to Excel works nicely!

Chris

Hi Chris

thank you very much for your detailed answer. This will help a lot.
There was just one typo in your VOToNetArray() function. In the inner Loop you Need the Count from the 2nd Dimension of the Array.

FUNCTION VOToNetArray(aVO AS ARRAY) AS System.Array
// hard coded for 2-dimension ARRAY
LOCAL aNet AS OBJECT[,]
aNet := OBJECT[,]{ALen(aVO) , ALen(aVO[1])}
FOR LOCAL i := 1 AS INT UPTO ALen(aVO)
FOR LOCAL j := 1 AS INT UPTO ALen(aVO[1])
anet[i,j] := aVO[i,j]
NEXT
NEXT
RETURN aNet

Here is the new documentation and the final Project file.
Thaks and have a nice rest of the Weekend.
Markus
Solution:


Documentation:

Hi Markus,

Thank you very much, all looking very good! It feels very nice and rewarding seeing more and more VO apps now running well in X#...

And thanks for the correction on the typo in my code, although this is very strange, because in the real code I had written it like that:

FOR LOCAL j := 1 AS INT UPTO ALen(aVO)

but it does not appear correctly in my previous message. Maybe a forum copy/paste issue, as an experiment let's see if it appears correctly in this post.

Chris

Heh, the code again doesn't appear correctly in my message! It was supposed to read:

aVO<left bracket>i<right bracket>

but I guess the forum software translates this as a control character, actually looks like it treats is as an italics control character and the rest of my message appeared in italic! That was a fun thing to debug

Chris