xsharp.eu

Hi Renee,

In that case, use DoEvents() function.

rjpajaron wrote:Hi Jamal,

I am still in VO GUI classes, hence the use of class App. Checking on X# docs, there is no DoEvents() method. Or I am missing something.

--

Rene

When the program stops without messages sometimes the following methods may help:
- Sometimes in the Windows event log a message can give more indications
- Create a dump file with the help of procdump that must be started for the running process. Then the dump file can be analyzed with Windbg Preview (the new Windbg version that can be downloaded from the Microsoft Store) or Visual Studio.
- Try to add try/end try blocks in different parts of the GUI events. Unfortunately this can be done only with an own compiled set of the GUI classes.

Hi Rene,

I did not question your sanity . Neither the quality of your work and VO code, in fact I am in no position to do that, after all the issues I saw I had in my own VO code, when I ported it as a test in X#!

They reason why I asked what your app is doing there at the end, is to get maybe a hint on what might be causing the crash. If it's doing dbf stuff, then there's where we should be looking into, if it's doing heavy calculations then maybe it's another thing etc.

Please try what Arne suggested, it's what I wanted to ask you to do as well, especially to check the event log and also add TRY/END blocks to catch the error. Also what happens if you run the app from inside VS (or XIDE) in debug mode, do you get some more information?

Thanks Everyone for the replies and I appreciate it so much.

I finally fixed the problem and it was my fault and being new to bBrowser 4.

I was in bBrowser 3 for so long and I have so many "illegal" calls that bBrowser 4 no longer permits.

Closing a table "use" on the bBrowser cannot be manually closed when settings on Auto Close is TRUE or when the table itself was already closed and disposed by the parent. Doing this crashes the whole app.

EXECWHILEEVENT is now working but how?
1. I experimented various code, of course, all failed.
2. I deleted DynSize(number) at the MainShellApp during the port process. I put it back and it works.
3. Question that beg an answer: DynSize(number) is no longer documented. But adding it back make EXECWHILEEVENT works. For me.
4. I have to delete CollectForced. I know this is the right thing to do because it was flag at X# docs as OBSOLETE.
5. But why DynSize is hidden?

My objective on X# Port is 100% compatibility with VO apps. It means: I can release a Beta by December and both VO and X# apps can run side by side with no problems. Hence, I do not (so tempting) to make drastic change.

VO apps we have is fully certified by "tax authorities" and other regulation bodies, I do not advertise this as another version upgrade. Our docs will never mention that this is "another" version to prevent "re-certification" process which is time consuming and expensive for us.

I am going to FOX, just waiting for our Treasurer to get out of lockdown from their own city.

Thanks everyone.

FYI: I have high-confidence on X# now, actually on myself. X# is OK level for me, but me? I am not yet OK. I have a lot to learn.

--

Rene

Hi Rene,
one of the big differences between VO and X# is that VO has its own garbage collector, whereas X# applications are executed in the #NET Framework runtime. Therefore (nearly) all calls that change the behavior of the garbage collector in VO are obsolete in X#.
And of course you may encounter different behaviors because the .NET GC is much more tested and powerful.
I had such an issue and discovered the cause only more than 2 years later (or better: Chris discovered it) - VO has a fault behavior in this specific case (dynamic menu shortcuts stopped working after some time because the .NET GC disposed them).
Wolfgang

Hi Rene,

This is the code of DynSize(), as it is defined in the X# runtime:
So as you can see, it definitely has no impact in the app
The reason why it is not supported (together with many other memory management functions) is what Wolfgang said, in .Net and X# it is not the X# runtime that has control of memory management, this is completely controlled by the .Net runtime itself and concepts like manually adjusting the available memory pool do not apply at all.

Although regarding Collect() in particular, this is also not supported either (its implementation again does nothing), but actually it can be implemented, because also in .Net it is possible to manually invoke the garbage collector, with GC.Collect(). But while in VO we very often have to use Collect() in order to workaround the shortcomings and bugs of the memory management system of VO, in .Net it is usually strongly advised to never invoke the GC manually, but instead let itself decide when it needs to be invoked. In 99% of the cases this works well, so I think it's better to not worry about it yet (and let your Collect() calls remain obsolete, doing nothing), until you possibly find a reason for changing this.

HI Chris,

I let you know, X# is great. I have crashes for weeks on test computers. But never able to duplicate on my laptop.

and I found out, I did not include all the files in %:Program Files (x86)XSharpRedist

Several *macrocompiler.* is missing on my test.

All is good. Except on missing prototypes on AdsMgGetUserNames() and AdsMgGetUserNames(). Actually, in closer inspection, majority of AdsMgXXXX are not yet supported and nowhere to be found on Xsharp.ADS.ACE32.

X# is great. Indeed, I was stupid to get a conclusion for myself that DynSize did solve all those crashes but I actually remove it altogether and still crashes was there. But eventually, all is gone when I move to public 2.6b and the ReportPro you have posted that are compatible with 2.6 and bBrowser update.

My mind now is focus on improve all code improvement to make it faster and leaner. Removing lots of code. Furthermore, happy to discover that FabTools is on GitHub also. Finally!!! Now, I am waiting for someone to post at GitHub the RightSLE. I am still using those. I have some complaints on Form Editor (it is rendering controls the wrong way). But not important at this point.

I have a lot to learn. and one of those things I always remember: LET .NET DO THE THING.

Regards,
Rene

Hi Wolfgang,

I learn the hard way. Reading is not enough. And I realized that I am on VS 2019 exclusively for 3 months already and I seldom open VO. Before, I use both almost in the same importance. Well, I do open VO every now and then to check the location of the code I am trying to fix in VS. I have been in VO for almost 23 years and the code that I have writing on it, I memorized the project layout that getting used to new layout I did on VS took a lot of time to adjust. Now, I am comfortable.

I really wish to do some stuff on X# on VS Code but not important at this point. Yes, .NET need to do its job and it is better to left it alone in doing it and that is MEMORY MANAGEMENT. Hands Off. My motto.

My folks in my company were happy that I finally made it. FOX subscription is now regular part of our R&D budget, officially next year but I will do something this following months to get the discount. This apps is "very" huge and mission critical to 100+ cooperatives all over the country. Took me 13 years to finally leave VO behind. 2007 is the year I see the value of Vulcan. and 23 years on VO. I keep my VO apps healthy, sort of. I keep reindexing it on daily basis just for the sentiments and torture I love doing for all those years.

I will keep VO apps running actually. Something I did not do on my Clipper 5.3 in '97. Someone ask me if I can recover my old CA-Clipper apps. I told them: I burned bridges in '97. Not this time though. Not just sentiments but for maintenance purposes.

--

Rene

Hi Rene,
you are right - reading alone is not enough, you need to try and work with it yourself.
Maybe I'm a particular case, but I already need to understand you things are put together, and slowly I'm understanding some things.
Contrarily to you I already have a lot of code in production that is written in X#, but is not using the VO classes and the runtime at all, but my main VO applications still need to be ported (I have a few smaller ex VO applications that are now running and maintained in X#, but none of the really large applications).
Maybe I will have more time to work on the migration since Italy will apply stronger restrictions starting from Monday morning...
Wolfgang