[Gambas-user] Migrating to Gambas

[Christof Thalhofer]

Am 10.06.21 um 08:58 schrieb Bruce:

> Christof, I fully accept that and agree, you would be mad to muck
> with stuff that works. However, are you saying a) you migrated it
> after those 10 years or are b) still using the MSA application? (Just
> to clear my understanding.)

Yes, you're right, I forgot to tell that this method was migrated to
Gambas afterwards (my whole application, of which it is a part, was
migrated). I had to tweak only small things and now it works in Gambas
for years without any problems.

> A bit further down he says
> 
> "Back to that two page function. Yes, I know, it’s just a simple 
> function to display a window, but it has grown little hairs and stuff
> on it and nobody knows why. Well, I’ll tell you why: those are bug
> fixes. One of them fixes that bug that Nancy had when she tried to
> install the thing on a computer that didn’t have Internet Explorer.
> Another one fixes that bug that occurs in low memory conditions.
> Another one fixes that bug that occurred when the file is on a floppy
> disk and the user yanks out the disk in the middle. That LoadLibrary
> call is ugly but it makes the code work on old versions of Windows
> 95."
> 
> That is the stuff I am talking about. Apart from maybe "that bug
> that occurs in low memory conditions" those bugs no longer exist in
> the known universe! Spending time "migrating" the remediant code is
> almost assuredly a waste of time. Better to understand (for want of a
> better word) the algorithm of the original code and code it.

Ok, did you realize that the text is from 2000? Win95 and IE are now
gone but were not at that time.

> Maybe you CAN paste the source code and delete vast chunks of 
> workarounds and patches that no longer apply and then start testing, 
> fixing, re-testing the new Gambas version. Maybe that DOES give you
> a "quickstart" into the Gambas version.

Ok, here I agree with you. I call that "refactoring" and for me, this
means not only adjusting the semantics and changing variable names, but
also rebuilding the code at the same time so that it is cleaner and
easier to understand.

But it is important to keep all the functionality and I have experienced
myself in my migration project that I had to add things again later that
I had removed because I thought they were unimportant. Although I had
written the whole junk myself(!?).

> Maybe. But my experience differs.

As it always happens.

> And one was a very similar case to yours, a "large" MSA code set, 4 
> "main" applications and from memory about 6-8 "library" applications.
> (I cant recall what they were called in MSA.) Anyway, we gave up on
> the whole "migrate" approach after a few weeks as, wait for it, there
> was stuff in the MSA code and forms that Gambas could not do. The
> typical one was comboboxes with keys that were driven by static
> metadata in the database that specified the key-value pairs and
> various attributes pertaining to those values.

If you think you can migrate a large MSA project to Gambas within few
weeks, you're wrong. I addressed exactly this problem by writing an
Access-like combobox and a tableview to rebuild this functionality in
Gambas and this alone cost me a couple weeks of development. As it was
one of the first things I have written in Gambas it is not so "gambassy"
as it should, but it does the job:

https://gitlab.com/christhal/gb.deg.form

Btw it is an "illegal" component, Benoît, if you're listening, could we
make it a legal component for Gambas as it is absolutely necessary for
people who want to migrate a MSA application to Gambas?

> Easy example "Error", key="ERR", background=red. The MSA code 
> "custom" control took care of all of that. Guess what! To this day I 
> have not been able to get Gambas/QT controls to emulate that
> behavior in a ComboBox. Another example was the
> Security/Authorisation code, which HAD to be re-written to the
> adoption of postgres as the underlying database.

I had used the MSA app to talk to Postgresql before, so this was easy. I
went to Gambas because MS had made it difficult to talk to Postgresql.

> Another was a "state machine" thing that most assuredly need never
> have been done in the first place, messy, buggy and totally lacking
> in any added value within the MSA code base anyhow. I think it was
> done when "state machines" were the buzz-word of the week. (Someone
> here was talking about these recently I think.)

Yes we talked about that. But in his case, it seems to be the right
architectural decision, since state machines are used to capture the
states of machines and reflect them in the software. And he uses it to
control machines.

> Anyway, the net result was that we excised almost ALL of the fancy
> code from the MSA base which left about 20% of the code - could have
> written it from scratch in Gambas using proper OO techniques in about
> half the time.
> 
> As always YMMV!

Yeah!

I think we meet in the middle.

Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur