TOPIC:

Hi!

I hope you don't mind if I keep reporting new bugs.

Now I have a problem with the values of a combobox.
I have a simple DialogWindow with a Combobox and a button to show the value of the selected item.

Here the code:

CLASS SomeData
EXPORT nValue AS INT
EXPORT cStr AS STRING

METHOD Init(n, c) CLASS SomeData
SELF:nValue := n
SELF:cStr := c

END CLASS



CLASS DialogHauptfenster INHERIT DialogHauptfensterAbstrakt

CONSTRUCTOR(oOwner)
SUPER(oOwner)

SELF:oDCComboBox1:AddItem("NULL", 0, NULL_OBJECT)
SELF:oDCComboBox1:AddItem("A", 0, SomeData{1, "a"})
SELF:oDCComboBox1:AddItem("B", 0, SomeData{2, "b"})
SELF:oDCComboBox1:AddItem("C", 0, SomeData{3, "c"})

SELF:oDCComboBox1:CurrentItemNo := 1
RETURN

METHOD ButtonShowData AS VOID PASCAL
LOCAL oSomeData AS SomeData
LOCAL oTB AS TextBox

IF SELF:oDCComboBox1:CurrentItemNo > 0
oSomeData := SELF:oDCComboBox1:GetItemValue(0) //The programm crashes here if the item with value NULL_OBJECT is choosen

IF !(oSomeData == NULL_OBJECT)
oTB := TextBox{, "Data", NTrim(oSomeData:nValue) + CRLF + oSomeData:cStr}
oTB:Show()
ELSE
oTB := TextBox{, "Data", "Null"}
oTB:Show()
ENDIF
ENDIF

END CLASS

If I choose item A, B or C everything is fine.

If I Choose the item with the NULL_OBJECT the programm crashes with "Das Objekt des Typs "System.String" kann nicht in Typ "SomeData" umgewandelt werden."

In VO the same code is working like expected an the MessageBox "NULL" is displayed.

Regards
Kai

Hi Kai,

We absolutely not mind reporting new bugs, we very much welcome them as they help making the product better! Of course, if you will find X# to be helpful for your bsuiness to bring your apps to .Net, it would be nice if you subscribed to the FOX program, in order to support its development.

Thanks for reporting this problem, turns out it boils down to this strange behavior of VO with the Default() function (code similar to that is called from the AddItem() method):


In VO, this prints TRUE in all four cases, while in X#, Default() changes the value of the usual, when it is executed, which is more logical I think. It will not be easy to emulate this behavior, but for compatibility with VO we need to do it one way or another (maybe change the code of AddItem() in the SDK). Will log this as well, thanks!

.

Hi Chris!

Thank you very much. If I use XSharp commercially one day I will of course subscribe.

But at the moment I'm still working hard to migrate my first application from VO to X# and I'm far away from the first commercial use.

The XSharp develpment team maks really, really a great job. But right now I think it needs a bit more development, especially the XIDE which is in my opinion not as productive as the VO IDE at the moment.

A big advantage of the VO editor is that I can open individual entities. In XSharp I can only open entire files, making it difficult to find specific entities in the file, especially when the entities are not sorted alphabetically and the file contains hundreds of entities..

Of course, the dropdown boxes, that show the file content, make things easier. The project explorer is also very helpful. But is it necessary to show all instance variables in the project explorer? It would be nice if I could hide the instance variables in the project explorer and if I could add a column showing the type of the entity. (class / constructor / method / access / assign, function, constant and so on...)

By the way: Not all developers are 20 years old and have best eyes. In my opinion, the Project Explorer font is too small even on larger notebook displays. My eyes start to hurt after a few hours of work. It would be nice if I could set the font size.

All in all XSharp is a wonderful project to bring the XBase languages ​​to the DotNet world, but in my opinion the productivity of the VO IDE is even better at the moment.

Of course, VO has several bugs, but over the years I've learned to work around these bugs.

For XSharp I now need to find the bugs and learn to work around these new bugs.

When this work is done and I can work with the XSharp IDE as fast as I can with the VO IDE, I will subscribe.

Thanks again to the XSharp-Team. You make a graet job.

Kai

Kai wrote:

...When this work is done and I can work with the XSharp IDE as fast as I can with the VO IDE, I will subscribe...
Kai

Well, valid point - as long as there are enough fellow folks, who pay NOW for the continuation of the live of the project. Even if there are only four valient man, who got und keep it going, they have to make a living. The less folk subscribe, the more they have to do "other" work for this, i.e. progress will be slower and you'll have to wait longer.

Hi Kai,

Hmm, I thought I had added an option in the explorer to hide fields, but apparently not. Will add this, I agree it will be helpful. Btw, usually I use the Goto Entity dialog (CTRL+G) to navigate in prg files, this one does have a hide fields option. But indeed it will not work well if you have a lot of classes in the same prg, so the suggested way to do it in a file based environment, is to divide the code in more prg files, so you do not have really huge prg files. Will also add the entity type column, makes sense also.

About the fonts used, those are the standard fonts used by windows. Maybe you should enlarge the fonts windows uses in the windows settings?

Hi Chris!

Next problem, this time verified and with code and dbf attached.

Please look at the following code:

LOCAL oDBServer AS DBServer
LOCAL oTB AS TextBox
LOCAL nSatzVon AS DWORD
LOCAL nSatzBis AS DWORD
LOCAL lEOFVon AS LOGIC
LOCAL lEOFBis AS LOGIC

oDBServer := DBServer{"c:\xsharp\test\zinfoex.dbf", DBSHARED, FALSE, "DBFCDX"}
oDBServer:SetIndex("c:\xsharp\test\zinfoex.cdx")

oDBServer:SetOrder("Timestamp") //Column: BTS
oDBServer:OrderTopScope := 220910000000
oDBServer:OrderBottomScope := 220910240000

oDBServer:GoBottom()
nSatzBis := oDBServer:RecNo
lEOFBis := oDBServer:EOF

oDBServer:GoTop()
nSatzVon := oDBServer:RecNo
lEOFVon := oDBServer:EOF


oTB := TextBox{, "Test", iif(lEOFVon, "T", "F") + " / " + NTrim(nSatzVon) + " / " + iif(lEOFBis, "T", "F") + " / " + NTrim(nSatzBis)}
oTB:Show()

oDBServer:Close()


The OrderTopScope value is LESS than the largest value in the BTS column.
The OrderBottonScope value is GRAETER than the largest value in the BTS column.

VO handles this as follows:

GoBottom: RecNo = 97 / EOF = false
GoTop: RecNo = 85 / EOF = false

XSharp handles this different:

GoBottom: RecNo = 98 / EOF = true
GoTop: RecNo = 85 / EOF = false


I use OrderTopScope / OrderBottonScope for example to calculate min / max value for a progressbar and process all records in the range. XSharp crashes in some cases:

local oDBServer as DBServer
local nSatzVon as DWORD
local nSatzBis as DWORD
local nAnzahl as DWORD

oDBServer := DBServer{"c:\xsharp\test\zinfoex.dbf", DBSHARED, FALSE, "DBFCDX"}
oDBServer:SetIndex("c:\xsharp\test\zinfoex.cdx")

oDBServer:SetOrder("Timestamp")
oDBServer:OrderTopScope := 220910000000
oDBServer:OrderBottomScope := 220910240000

oDBServer:GoBottom()
nSatzBis := oDBServer:OrderKeyNo()

oDBServer:GoTop()
nSatzVon := oDBServer:OrderKeyNo()

nAnzahl = nSatzBis - nSatzVon + 1 //XSharp crashes here with a numeric overflow since nSatzBis is 0 and nSatzVon is > 0

while !oDBServer:EOF
...
oDBServer:Skip()
enddo



Regards
Kai

Hi Kai,
please permit me to jump in here as heavy XIDE user: I'm missing too the possibility to open only the needed entities as VO can do, but I can assure you that currently I'm more productive in XIDE than in VO.
In XIDE, you can (and should IMHO) collapse all your entities you don't need, and then you should reorganize your code with the new possibilities XIDE can give you like the regions with #region / #endregion, and, what I really like, the possibility to organize your code not only in modules like VO, but to add subfolders.
Let me make an example: in VO, for each window (even with many tabwindows) I have always two modules: ones with the WED generated code and a classname that starts with an underscore, and a second one with all the handwritten code (my largest code module has 19320 lines of code and takes several minutes to load if I load it all).
When migrating to X#, IMHO the best option would be to build a subfolder for the entire window code, take one prg file for the generated file and an own file for each class, that means one file per subwindow, and one for the main window.
That makes is much, much easier to manage.
Unfortunately it is not possible to use a thing like the repository in X# because the compiler cannot support that.
Wolfgang
P.S. I have moved the explorer pane to the left side of the XIDE screen, so it looks much more familiar.

Hi Wolfgang!

I'm not a heavy XSharp/XIDE user yet. Otherwise I really would have already subscribed.

I have two large applications, witten in VO. The largest has over a million lines of code. I think it's a good idea to prepare it for migration to XSharp if one day the VO code stops working due to a windows update.

I can only repeat: In my opinion, the complete XSharp system is a really great tool, the VOExporter works perfectly for me.

But there are still a few things that prevent me from using it professionally. The IDE is one thing.

I've been using VO for more than 25 years now. The first versions were disastrous. Version 2.8 SP3 works fine for me. I know the problems that still exist and work around them. The VO IDE is clear and the compiler is fast.

My first step into the .net world was a Vulcan Trial in 2013. I imported an application and the result was not bad. I had a lot of work to do at the time, so I didn't continue working on Vulcan.

The next try was in January of this year with XSharp, but it took me more than 30 minutes to compile a file that compiled in VO in less than a minute. Now I think something was wrong with the notebook. Now I have a notebook with Core I7 and 16 gig RAM. Now the same application is compiled in XSharp in less than 60 seconds.

I have now imported parts of my largest application and the more I test the result the more problems I find. I'm still working on it, but it's a bit frustrating because the application has been extremely stable in VO and I'm finding new problems every minute now.

I'll report on my progress if you don't mind. And if I find any other problems that I can prove with examples, I'll report them.

Thank you for your support.
Kai

Hi Kai,
let me explain what my way was to my current situation: I started with Vulcan to write a small Windows Forms application and several command line helpers, but was never able to do any larger work with it.
Only when X# was presented, I started to write more serious code with it, and today most of my VO applications are unthinkable without their X# COM modules that are playing a more and more important role.
Other than that, we have 3 VOGUI based customer applications in production (all of them started in VO, but were moved to X# during development, and they are using ported version of our VO framework.
And new applications, if possible, are written using the X# Core dialect and WPF, and nearly all of them are also accessing VO data through the X# RDDs.
Currently, about half of my programming time is passed in VO, and the other half using X# in XIDE.
Of course, it is not easy to port a large application to X# - and I know a company here in South Tyrol that was able to port their very large VO application to X#. So it is possible, but it really depends on your programming style and the code used in your application how many work such a project can be.
So, if you need help in the migration, maybe you ask Robert for help, as he does also consulting work, and generally money spent on such help is very well spent money.
And yes, here you will find any help, and maybe also tricks and tips how to make your migration as easy as possible.
Wolfgang
P.S. in the few code migrations I have done I was able to find code that should never have worked in VO but it did - and I have found many bugs that I was never able to find during the VO period of life of the application

Hi Kai,

Thanks for the detailed report! Indeed I see the problem, also noticed a couple more similar problems with slightly different data, will log them all so they will be taken care of.

The overflow exception I think is correct though, since indeed an overflow happens in the arithmetic operation(s). But if you want, you can disable runtime overflow checking, by unchecking the "/ovf" and "/fovf" compiler options in the app properties window.

.

Hi Chris!

Of course, the overflow exception is correct. I just documented it to show you where the program crashes.