Harbour MiniGUI Extended Edition build 19.08 is published

[PeteWG]

Hi Friends,

We are pleased to announce a new build of Harbour MiniGUI Extended Edition.

It is a regularly scheduled maintenance and bugfix release.

Congrats and thank you!
With your efforts, Minigui has evolved to a quite good GUI (and no only) library.
What it needs, is a good `code refactoring` (I mean really good...)
and it will become a real masterpiece for Win32 desktop programming[*].

[*]even if, with all this "frenzy" for web programming, Win32 desktop programming
does not seem to be trendy anymore, as was the case 1-2 decades ago,
still it's going to be present for a reasonable amount of time, not less for one more decade, in future.


regards,
Pete

[gfilatov]

What it needs, is a good `code refactoring`

Which code refactoring you are need

Please be so kind to explain it more...

[PeteWG]

What it needs, is a good `code refactoring`

Which code refactoring you are need

Please be so kind to explain it more...

Hi Grigory,
and please, don't get alarmed!

when I say "it needs refactoring", it is not any kind of criticism to your uninterrupted excellent work all this years,
(as well as, the work of whole minigui team and anyone who helped and keeps helping), without which this great tool
would not be what it is.

Basically, with refactoring I do mean (between other) two things :

1) Update older minigui code-base, so to conform with many Harbour modifications during years of development,
improvements and new functions that did not exist the time the initial minigui code was written, etc.
- a good example is hbwin library of Harbour, which offers a lot of WINAPI functions that could be used
directly in place of minigui functions with similar or even same functionality, something that would help to
reduce the total library bloat and would make the sources harmonized to the Harbour main toolset.

2) A better organization of modules, f.e. there are many functions scattered through different .prgs
that probably makes it hard to keep an account of which utility function is available and what's the
purpose it serves, which thing in turns makes difficult for a potentially interested developer to get
into code and to attempt any changes and improvements.


I know that the above things need human-hours of work, for to carefully reviewing the existing code and applying changes. And the question is, who would do that work and for what benefit.
So the "need for refactoring" is a perpetual requisiteness and an always present `TODO!` plan, which is not necessary to be directet to some individual developer, it is rather a thing that must concerning every developer regarding the tools he uses to create his applications.
I would say that are we the users of minigui that we should be engaged more energetically to locate things that need improvments and propose possible solutions. In other words, collaboration!
But for this thing to happen perhaps requires the minigui to be hosted in a repository at Github, which would help the project to draw attention
on a wider circle of developers and possible attract some of them to contribute ideas, code, etc.

regards,
Pete

[gfilatov]

Basically, with refactoring I do mean (between other) two things :

1) Update older minigui code-base, so to conform with many Harbour modifications during years of development,
improvements and new functions that did not exist the time the initial minigui code was written, etc.
- a good example is hbwin library of Harbour, which offers a lot of WINAPI functions that could be used
directly in place of minigui functions with similar or even same functionality, something that would help to
reduce the total library bloat and would make the sources harmonized to the Harbour main toolset.

2) A better organization of modules, f.e. there are many functions scattered through different .prgs
that probably makes it hard to keep an account of which utility function is available and what's the
purpose it serves, which thing in turns makes difficult for a potentially interested developer to get
into code and to attempt any changes and improvements.

Hi Pete,

Thanks a lot for your explanation
It is more understandably now

And you are know my conceptual approach:
"I'm open for any useful contribution in the project."

[dragancesu]

error reporting

if the dbf field is called "NO", the compiler reports an error
seems the precompiler change "NO" to .F.

[gfilatov]

error reporting

if the dbf field is called "NO", the compiler reports an error
seems the precompiler change "NO" to .F.

Hi Dragan,

There is not an error here because the standard Harbour header file common.ch contains the following definitions:

/* Friendly logical aliases */
#define TRUE .T.
#define FALSE .F.
#define YES .T.
#define NO .F.

But you can undefine always above unneeded conversion with

Code: Select all

#ifdef NO
   #undef NO
#endif 

before HMG header calling

[dragancesu]

Believe or not, compile with HMG 3.4.4 is without error

[gfilatov]

Believe or not, compile with HMG 3.4.4 is without error

I believe... because HMG 3.4.4 are NOT included the definitions from the Harbour header common.ch by default.

[gfilatov]

Hi All,

I've uploaded the updated setup of the build 19.08 for Borland C++ 5.5.1 at

http://hmgextended.com/files/CONTRIB/hm ... -setup.exe

Whatsnew:

* Enhanced: Added possibility to modify of 'OnDblClick' event for the LABEL
and IMAGE controls at run-time with:
- function syntax:
SetProperty(Form,Control,'OnDblClick',{|| MsgInfo('New action')})
- pseudo-OOP syntax:
Form.Control.OnDblClick := {|| MsgInfo('New action')}
Contributed by Grigory Filatov <gfilatov@inbox.ru>
(see demo in folder \samples\Advanced\MP3Info)
* Enhanced: Added possibility of in-line usage of the commands
[DE]ACTIVATE TIMER <name> OF <parent> for the Timer control.
Contributed by Grigory Filatov <gfilatov@inbox.ru>
(see demo in folder \samples\Advanced\MP3Info)
* Updated: HbSQLite3 library:
- update for using SQLITE3 version 3.30.0dev (from 3.29.0).
Contributed by Grigory Filatov <gfilatov@inbox.ru>
* New: 'MP3 Info Class Test' sample. Based upon a contribution of
Victor Daniel Cuatecatl Leon for FiveWin library.
Adapted for Minigui Extended by Grigory Filatov <gfilatov@inbox.ru>
(see in folder \samples\Advanced\TestMP3Info)
* Updated: 'Replacement for Clipper ALERT() function' sample:
- New: using of the codeblock bOnInit in the Alert* functions.
Contributed by Grigory Filatov <gfilatov@inbox.ru>
(see in folder \samples\Basic\WALERT_2)
* Updated: 'DOS-like menu with using of TsBrowse' sample.
- updated for the recent changes in Minigui core.
Problem was reported by Verchenko Andrey.
(see in folder \samples\Advanced\Tsb_menu)

The upgrade to this build is optional.

Please note that there are also the private MiniGUI builds for the following
well-known free C-compilers:

- MinGW GNU C 9.2.1 (32-bit);
- MinGW GNU C 8.2.0 (64-bit);

- MS Visual C++ 2019 (32-bit);
- MS Visual C++ 2019 (64-bit).

Thanks for your attention.

--
Best Regards,
Grigory Filatov
[MiniGUI Team]

[Anand]

Thank you for the update.

Regards,

Anand