Harbour MiniGUI 1.7 Extended Edition (Build 75) Released

CCH : From the HMG Extended Forum

Hi All,

The Harbour MiniGUI 1.7 Extended Edition (Build 75) setup is published at the following URL:

http://hmgextended.com/files/CONTRIB/hmg-1.7-75-setup.zip

and the Lite build 75 at the following URL:

http://hmgextended.com/files/CONTRIB/hmg-1.7-75-setup-lite.zip

There is the following changelog for this build below:

2009/10/21: Build 75 (HMG 1.7 Extended Edition) Published.
* New: 'Application' object. It will allow to read (and write when possible)
various application main window properties.
Syntax:
Application.ExeName
Application.Handle
Application.FormName

Application.Col [ := ]
Application.Row [ := ]
Application.Width [ := ]
Application.Height [ := ]
Application.Title [ := ]
Application.Cursor :=
Application.BackColor :=
Application.Topmost :=
(see demo in folder \samples\Basic\MULTI_PRG)
Contributed by Grigory Filatov <gfilatov@freemail.ru>
* New: Added a pseudo-function ChangeFileExt( , ). It will return
the full filename with changed extension.
Usage:
cFileIni := ChangeFileExt( Application.ExeName, '.ini' )
Based upon an idea borrowed from Delphi.
Contributed by Grigory Filatov <gfilatov@freemail.ru>
* Fixed: The declaration for all minigui defined functions/procedures.
Problem was reported by Rossine <qiinfo@ig.com.br>
(see mgextern.ch in folder \include)
* Fixed: The Up/Down moving issues in "Browse from rc" and "Browse indirect".
Problem was reported by Jaroslav Janik <jaroslav.janik@siemens.com>.
Contributed by Janusz Pora <januszpora@onet.eu>
(see demo in folder \samples\Basic\Dialog)
* Changed: Function GetFile() - minor correction in the multiselect mode.
Requested by Ryszard Rylko <rrylko@cirow.pl>.
Contributed by Grigory Filatov <gfilatov@freemail.ru>
(see demo in folder \samples\Basic\GetFile)
* Updated: Synchronized an Extended HMG with an Official HMG 2.7.0:
- New: 'System' object. It will allow to read (and write when possible)
various operating system properties.
The first implementation allows to access (read and write) the system
clipboard and various system settings (read only).
Syntax:
System.Clipboard [ := ]

System.DesktopWidth
System.DesktopHeight
System.DefaultPrinter
System.DesktopFolder
System.MyDocumentsFolder
System.ProgramFilesFolder
System.SystemFolder
System.TempFolder
System.WindowsFolder
(see demo in folder \samples\Basic\CLIPBOARD).
* Updated: Synchronized an Extended HMG with an Official HMG 3.0.0:
- New: 'Build.bat' is based upon HBMK2 utility (it works at WinXP and later).
Syntax:
Build [/d] [/i] [/r] | [config.hbc]
where
[/d] : Debug Mode
[/i] : Incremental Build
[/r] : Rebuild All Mode

: A text file with a source filelist
: A text file with configuration parameters as additional
libs, include paths and lib paths
(see demos in folders \samples\Basic\MULTI_PRG and \samples\Basic\MAINDEMO (SYNTAX I))
* Updated: WinReport library (see source in folder \Source\WinReport).
Contributed by Pierpaolo Martinello alice.it>
(see demo in folder \samples\Advanced\REPORT_
INTERPRETER and
help file WinReport.chm in folder \Doc)
* Updated: Socket library v.1.07:
- Fixed: minor correction in the C-function SocketReceive()
Suggested by Przemyslaw Czerpak (druzus/at/priv.onet.pl).
(see socket.c in folder \Source\Socket)
* Updated: HbSQLite3 library source code (see in folder \Source\HbSQLite3):
- updated for using SQLITE3 version 3.6.19
Contributed by Grigory Filatov <gfilatov@freemail.ru>
(see demos in folders \samples\Advanced\SQLITE and \samples\Advanced\SQLITE_2)
* Updated: Harbour Compiler 2.0.0beta3 (SVN 2009-10-20 01:20):
* New: Memory File System usage (see demo in folder \samples\Advanced\MEMORY_TABLES).
Contributed by Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt)
* Updated: HbSqlDD library source code (see in folder \Source\HbSqlDD).
Problem was reported by Luiz Escobar <escobar@megasistema.com.br>.
Contributed by Grigory Filatov <gfilatov@freemail.ru>
(look at ReadMe.txt in folder \harbour and WhatsNew.txt in folder \harbour\doc)
* Updated: HMGS-IDE v.0.9.4.2. Project Manager and Two-Way Visual Form Designer.
Contributed by Walter Formigoni <walter.formigoni@uol.com.br>
(look at changelog.txt in folder \Ide)
* New: 'My Dbf Browse' sample. Based upon a contribution by MigSoft <fugaz_cl@yahoo.es>
(see in folder \samples\Basic\BROWSE_8)
* Updated: 'Report Generator' sample by Roberto Lopez <harbourminigui@gmail.com>:
- added array support.
Syntax:
BEGIN DATA
ITERATOR
STOPPER
END DATA
The section is optional. If its omitted, 'Iterator' will be set as 'dbskip()'
and 'Stopper' as 'Eof()'. Borrowed from an Official HMG 2.9.5.
Adapted for Minigui Extended by Grigory Filatov <gfilatov@freemail.ru>
(see demo8.prg in folder \samples\Advanced\REPORT_GENERATOR)
* Updated: Applications for compatibility with the last Harbour changes:
- 'Switch Printer' (see in folder \samples\Applications\SwitchPrinter);
- 'System Info' (see in folder \samples\Applications\SysInfo).
Contributed by Grigory Filatov <gfilatov@freemail.ru>

This release of MiniGUI is considered stable and ready for production use.

Your comments are welcome!

--
Best Regards,
Grigory Filatov
[MiniGUI Team]

Harbour beta3 allows to use the Memory File System.

CCH : From the HMG Extended Forum

The Harbour beta3 allows to use the Memory File System.
This feature is based upon a new contribution HbMemIO by Mindaugas Kavaliauskas.
It will be available at the next HMG EE build (coming soon).
Take a look for the following sample (adapted for MiniGUI):

/*
* MINIGUI - Harbour Win32 GUI library Demo
*
* Copyright 2002-2009 Roberto Lopez <harbourminigui@gmail.com>
* http://harbourminigui.googlepages.com/
*
* Copyright 2009 Grigory Filatov <gfilatov@freemail.ru>
*
* Based on MEMIO sample included in Harbour distribution
*/

#include "minigui.ch"

REQUEST HB_MEMIO

*-----------------------------

---------------------------*
Function Main()
*--------------------------------------------------------*

DEFINE WINDOW Form_1 ;
AT 0,0 ;
WIDTH 640 HEIGHT 480 ;
TITLE 'Memory File System Demo' ;
MAIN NOMAXIMIZE ;
ON INIT OpenTable() ;
ON RELEASE CloseTable()

DEFINE MAIN MENU

DEFINE POPUP 'Test'
ITEM "Exit" ACTION ThisWindow.Release()
END POPUP

END MENU

@ 10,10 BROWSE Browse_1 ;
WIDTH 610 ;
HEIGHT 390 ;
HEADERS { 'Code' , 'Name' , 'Residents' } ;
WIDTHS { 50 , 160 , 100 } ;
WORKAREA memarea ;
FIELDS { 'Code' , 'Name' , 'Residents' } ;
JUSTIFY { BROWSE_JTFY_LEFT, BROWSE_JTFY_LEFT, BROWSE_JTFY_RIGHT } ;
EDIT ;
INPLACE ;
READONLY { .T. , .F. , .F. }

END WINDOW

CENTER WINDOW Form_1

ACTIVATE WINDOW Form_1

Return nil

*--------------------------------------------------------*
Procedure OpenTable
*--------------------------------------------------------*

CreateTable()

INDEX ON FIELD->RESIDENTS TAG residents

GO TOP

Return

*--------------------------------------------------------*
Procedure CloseTable
*--------------------------------------------------------*

DBCLOSEAREA()
DBDROP("mem:test") // Free memory resource

Return

*--------------------------------------------------------*
Function CreateTable
*--------------------------------------------------------*

DBCREATE("mem:test", {{"CODE", "C", 3, 0},{"NAME", "C", 50, 0},{"RESIDENTS", "N", 11, 0}},, .T., "memarea")

DBAPPEND()
REPLACE CODE WITH 'LTU', NAME WITH 'Lithuania', RESIDENTS WITH 3369600
DBAPPEND()
REPLACE CODE WITH 'USA', NAME WITH 'United States of America', RESIDENTS WITH 305397000
DBAPPEND()
REPLACE CODE WITH 'POR', NAME WITH 'Portugal', RESIDENTS WITH 10617600
DBAPPEND()
REPLACE CODE WITH 'POL', NAME WITH 'Poland', RESIDENTS WITH 38115967
DBAPPEND()
REPLACE CODE WITH 'AUS', NAME WITH 'Australia', RESIDENTS WITH 21446187
DBAPPEND()
REPLACE CODE WITH 'FRA', NAME WITH 'France', RESIDENTS WITH 64473140
DBAPPEND()
REPLACE CODE WITH 'RUS', NAME WITH 'Russia', RESIDENTS WITH 141900000

Return Nil

--
Regards,
Grigory

HMG Version 3.0 ... on the way

CCH : Looks as if the HMG Version 3.0 is on the way :-)

HMG 3.0.0 (Test V) Changelog:

English:
--------

- Updated: Harbour compiler to 2.0 (Created from SVN 2009.10.14).
HMG IDE 2.9.4 and earlier versions ARE NOT COMPATIBLE with this
HMG version.

- Updated: MingW compiler to 4.4.1

- Modified: Samples.

Removed: ADORDD samples (adordd not working on
current Harbour release)

Added: RDDSQL samples.

-\HMG\SAMPLES\RDD.SQL\MYSQL
-\HMG\SAMPLES\RDD.SQL\ODBC
-\HMG\SAMPLES\RDD.SQL\ARRAY
-\HMG\SAMPLES\MEMORY.TABLES
-\HMG\SAMPLES\MULTI.WIN

New: 'Build.bat' (it replaces 'compile.bat').

Build [/i|/r|/d|/cs|/ci/cr] | [config.hbc]

[/i] : incremental build
[/r] : incremental build (rebuild all)

[/cs] : Console/mixed mode (std build)
[/ci] : Console/mixed mode (incremental build)
[/cr] : Console/mixed mode (incremental rebuild all)

[/d] : Debug mode (gui and console)

: A text file with .hbp extension containing a source list
: A text file with configuration parameters as additional
libs, include paths and lib paths.

Syntax:

incpaths = incpath1 incpath2 ... incpathn

libpaths = libpath1 libpath2 ... libpathn

libs = lib1 lib2 ... libn

library names must not include 'lib' prefix nor '.a' extension.

Sample: \HMG\SAMPLES\MULTI.PRG

More at http://hmgforum.com

Using ADORDD with Harbour/xHarbour

Using Delphi 5 and subsequently Delphi 7, I have been using ADO to connect to databases such as MS/SQL and MySql without much issues. So in my exploration of Harbour, I note with interest that one can connect to various databases via ADORdd

Apparently Antonio Linares announce the availability of AdoRDD on 26 April 2007 and since then there have been 169 follow-up posts. There has also been some discussions on AdoRDD in the Harbour Main Developers List as well

This is what Antonio Linares posted quoted verbatim

New AdoRDD (free)

FiveTech Software and noway www.noway.com are proud to announce the availability of an early release of the ADORDD for Harbour and xHarbour. This RDD is planned to be included in the Harbour CVS so we welcome all ADO users to start testing it and colaborating in its development.

Actually this code is already working:

REQUEST ADORDD

FUNCTION Main()

USE test.mdb VIA "ADORDD"

BROWSE()

USE

RETURN nil

It has already been tested with Access and MySQL, but it should work with any DataBase engine that supports ADO.

best regards,

www.ViaOpen.com

noway www.noway.com
Fernando Mancera (Updated 20/1/2010)

Last edited by Antonio Linares on Thu May 03, 2007 11:20 am, edited 1 time in total.

regards, saludos

Antonio Linares
www.fivetechsoft.com

HMGS-IDE 0.9.4.2 is released - 11th October 2009

CCH : From the HMG-Extended Forum

Hi All,

The updated HMGS-IDE 0.9.4.2 binary and sources are published
at the following URL:
http://www.hmgextended.com/files/HMGS-IDE/ide.zip

There is the following changelog for this version:

2009-10-10: version 0.9.4.2
*Fixed : Saving value property of TBrowse control. Bug was reported by Jaroslav Janik <Jaroslav.Janik@siemens.com>. Contribution by Grigory Filatov <gfilatov@rambler.ru>

--
Kind Regards,
Grigory Filatov
[MiniGUI Team]

Why does HMG use a customised version of Harbour ?

CCH : From the Harbour Main Developers List

Date: Mon, 05 Oct 2009 13:56:26 -0300
From: Roberto Lopez <roberbox@gmail.com>
Subject: Re: [Harbour] Wich is the official harbour's user group?

Massimo Belgrano wrote:

 > Please Roberto lopez when you see this messages post your right reply
 >
 > Will harbour and hmg share an harbour corner to made assistance to
 > either final user?
 >

At first, regarding the name:

When I've created the library, It was only a simple experiment about
Harbour-C interface, so, I've not care about the name so much :)

I've picked "MiniGUI" because the library featured only a minimal
functionality/GUI object set, so, it appeared to be a good choice.

Some time later, I've realized that a Linux product existed with the
same name, so I've decided to add 'Harbour' to the name.

 From that time, the library was called 'Harbour MiniGUI'. So, avoiding
the name conflict and also made clear my compiler preferece.

There was another problem to solve, I had LOTS of support requests
regarding issues about Harbour and C compiler installation/compatibility.

Then I've decided to package all needed things ready to use with zero
configuration (this was possible with the great help of Lorenzo Fiorini
on MingW compatibility issues).

 From the first 'ready to use' distribution (MiniGUI library + MingW +
Harbour) I've decided to use an alternate name: "HMG". Of course, it
stands for *H*arbour *M*ini *G*ui (indeed, "Harbour MiniGUI" is a not
good one name at all :) )

Regarding the HMG Forum, Viktor is rigth about that the Harbour version
bundled with HMG is a customized version. Moreover, the customization is
minimal (contrib library names are not changed).

Moreover, there is certainly a lack of 'official' Harbour support to users.

Across years I've received tons of bugs reports about Harbour, that I
can't handle because lack of time or knowledge (mostly about
rdd/database issues).

Harbour official users lists is usually inactive, then, some users come
here (not the right place, of course).

HMG Forum site owner and admin is Rathinagiri (a long time HMG user and
contributor) so, he is the right person to ask about this.

 From my part (I've not followed the complete thread about this) there
is no problem to add a specific area on the forum to give support to
Harbour compiler specific issues, but, of course, we will need the
collaboration of some of the Harbour 'masters' to succeed.

 From about one year ago, HMG includes Harbour 1.01 and MingW 3.4.5, so
most questions will surely related to that combo (I'm waiting for
Harbour 2.0 final to replace 1.01 and MingW with 4.x).


Regards,

Roberto.
5th October 2009

Updated on 7th October 2009

Date: Tue, 06 Oct 2009 15:04:50 -0300
From: Roberto Lopez <roberbox@gmail.com>
Subject: Re: [Harbour] Wich is the official harbour's user group?

Viktor Szakáts wrote:

> [ Still not all though, as there exists another package called
> MiniGUI Extended, which actually ships with Harbour 2.0.0b2,

There was only one project from 2002 to 2005 (the one I've started) from
then, two forks emerged: "HMG extended" and "OOHG" (I'm only responsible
for "HMG").

> It's really your project and your decision, but IMO it'd be a big
> step if you'd use a vanilla Harbour build (without customization).
> This way it'd be easier to swap components and general Harbour support
> could be given for both bundled and standalone Harbour distros without
> first identifying which build is in question. Moreover, general
> Harbour support could be given at any forums without being concerned
> about where this build comes from. Same goes for MiniGUI: Support
> could be given even here or other official or unofficial Harbour
> forums.

It's a good idea.

The current HMG distribution uses Harbour 1.01 for MingW build
downloaded from Sourceforge. I've removed 'binutils' not required by HMG
and (of course) added libraries and other things, but this shoud be not
  create problems regarding Harbour compiler support.

Moreover, I'll begin experimenting with Harbour 2.0 beta and publish a
test HMG release ASAP.

If something goes wrong, I'll seek for help here, prior to attempt a
dirty hack, I promise :)

So, hopefully, we will have full 'Harbour support compatible' HMG releases.


Regards,

Roberto
 

Inclusion of LetoDB in Harbour Project ?

CCH : An interesting discussion in the Harbour Project Main Developer List on 2nd Oct 2009


Date: Fri, 2 Oct 2009 20:35:32 +0400
From: Alexandr Okhotnikov

Hi

Take as an axiom: in the harbour need open replacement ADS (for
multi-user environment) for those who still uses DBF and can not be
(not wants) to switch to SQL

2009/10/2 Przemyslaw Czerpak :
> Hi All,
>
> 1. it tries to use DBF record buffer but does not support all field types
> and features supported by core DBF* RDDs
> 2. it does not support timestamp values

The main types are (my opinion that this long enough), add the rest
later (for DBF, they are not critical)

> 3. numeric values in some operations like SEEK are converted to strings so
> they cannot be safely used with double values because such conversions
> round them to number of decimal places used to show numeric item on
> the screen

SEEK: for numeric fields to translate a string based on the dimension
of the field (no loss of accuracy)

> 4. it does not optimize multirecord skips on filtered or set_deleted
> workareas
> 5. it does not use aliases on server side so expressions sent to server
> cannot use aliases too (.f. index key/for, filters, ...)
> 6. relations are implemented only on client side and this code is not
> finished - it needs fixes in many places,
> missing server side relations seriously reduce functionality and
> performance in programs which use aliases though without server side
> support for aliases it still not be fully usable.

Using ADS almost the same :)

> 7. it does not respect many of _SET_* settings and also does not inform
> server about settings like _SET_DATEFORMAT, _SET_EPOCH, _SET_TIMEFORMAT,
> _SET_DECIMALS, _SET_FIXED, _SET_EXACT, ... which are important for
> correct execution of user expressions on server side

I think to finish (or customize a specific case) will not take much time

> 8. some important RDDI_*, DBI_*, DBOI_*, DBRI_*, DBS_* actions are not
> implemented at all or are implemented wrongly what breaks some other
> code, i.e. there is no DBI_GETLOCKARRAY so dbRlockList() function does
> not work or it informs GT that it uses DBF compatible record buffer
> and can transfer whole records but such functionality is not implemented
> so optimized by RDD code COPY TO ... and APPEND FROM ... operations
> fail
> 9. it tries to optimize some operations like dbAppend() but it's done
> in unsafe way which is not compatible with Clipper RDDs, i.e. dbAppend()
> is buffered and always return success though other client may set
> FLOCK() on the table so it will fail later when such appended record
> is sent to the server. For some programs it introduce other bugs
> because some algorithms may use APPEND rlocks for synchronization
> and to protect other stations against setting FLOCK so such behavior
> will causes total desynchronization

Confirm

> 10. in some methods it does not send all parameters and settings to server
> so some operations may not work as expected, i.e. important ordCondSet()
> settings are not transfer to server side
> 11. some methods are implemented as dummy ones what only disables error
> messages when user tries to use them so he does not even know that
> they failed silently,
> such things have to be eliminated and I hope it's only unfinished code
> 12. some operations are hacked to work only in some very limited
> situations, i.e. DBOI_KEYADD/DBOI_KEYDELETE works only with string
> key values which does not have any embedded 0
> 13. some things are implemented wrongly, i.e. if current record is
> locked (unlocked) then dbRlock( ) (dbRUnLock( ))
> calls are ignored
> 14. the transaction code also looks like unfinished, now it makes only
> one thing: it delays sending modifications to the server side with
> only very basic support for modifying the same record more then once,
> it may be usable in some applications but probably breaks most of
> programs which were not designed from beginning to work with RDDs where
> modifications are not visible during updates, missing documentation
> for exact isolation level causes that such transactions can be safely
> used only by LETO code authors who well know the internal behavior
> and created .prg code compatible with it
> 15. it's not MT safe and needs very serious internal modifications
> to work with user MT applications. As I can see so far it's
> not ever defined how it should be done so it's necessary to
> design such model from scratch.
> 16. it encodes/decodes messages using sprintf()/sscanf() functions
> what introduce some additional problems, i.e.:
> - this is very slow method of data encoding and decoding though
> in comparison to TCP/IP delay it's not critical
> - C compilers quite often provide *printf()/*scanf() functions
> in two version for ST and MT modes so for MT mode it's very important
> to use MT safe CRTL and leto code have to be always compiled with MT
> C compiler flags. We have our own hb_sprintf() function which is
> fully reentrant safe but we do not support hb_sscanf() so it's
> potential problem
> - it's very unsafe and hard to protect against buffer overflow and
> current leto code has a lot of potential buffer overflows which
> can cause server or client crash or hangup if user pass some data
> exploiting them
> - these functions operate on text data but LetoDB needs to transfer also
> binary data so programmers have to mix text and binary data what
> complicates message format and is source of some mistakes/bugs,
> now some messages are wrongly encoded what may cause server or
> client hangup

I did not look so deep

> 17. I do not see any documentation for the protocol, looks that each
> new message is added "as is" to client and server code, it means
> that even now it's hard to introduce extensions without careful
> checking of existing code to avoid possible conflicts,
> 18. I do not see any documentation which divides actions on client
> and server side so it's hard to add the extensions keeping
> original author vision, in the moment when such projects
> stops to be single author code such at least very basic
> documentation is a must, otherwise we will end with set of
> functions and RDD methods often replicating existing functionality
> because each developer tried to resolved his local problems in
> his own way, it also causes that bug fixing is very hard because
> developers seeing that sth is potentially wrong have to analyze
> whole code for possible workarounds in different places, i.e.
> I'm not able to verify everything what I see after looking at
> this code without investing day or two in deep analyzing

And that, in the harbour is not so?
I could not find documentation on the RDD (as in the rest of the
implementation of what either), but this does not prevent me to use
the harbour

> 19. it does not use hbsocket.h API so it may have portability problems
> and it does not address some problems which existed in original
> Giancarlo Inet* implementation and were copied to LetoDB
> 20. server uses internally own threads but does not use hbthread.h API
> what creates problems with portability and adding some extensions
> in the future, i.e. simultaneous executing .prg code by such threads
> is impossible now, it also blocks using HVM threads which could
> resolve important problems in current server implementation

Maybe, maybe not

> 21. I do not understand some parts of server code, i.e. there
> is an option to reuse existing tables between connections but
> why it was added? It cannot work without disabling most of
> server side processing because there is only single area
> structure so everything have to be shared between clients
> what creates series of problems, i.e. filter set by one client
> changes other client skip/seek operations, etc.
> I cannot even say that it is work in progress because it will
> never be fully functional option

Checked - everything is working properly

> 22. it keeps support for some old Harbour and xHarbour compilers
> what in few places makes the code more complicated and less
> readable then necessary, in some cases like own non HVM threads
> it seriously limits farther developing so such support have to be
> removed if we want to resolve all above problems
>
> best regards,
> Przemek

As a result, there is no alternative to ADS (DBFCDX use the network impossible)
and are forced to buy xHarbour (where it is more or less available)

All the above is my personal opinion

LetoDB - works (may not always correctly, but can be used)
I vote for inclusion in the harbour

Best regards,
Alexander


Response by Viktor

Date: Fri, 2 Oct 2009 20:07:25 +0200
From: Viktor Szak?ts <harbour.01@syenar.hu>

Hi Przemek and All,

Thanks for the insightful comments and detailed code analysis.

For me the conclusion for now is that while it would be nice
to "refactor" (hate the word) LetoDB code so that it 'becomes'
Harbour quality and most probably a viable FOSS ADS replacement,
this whole work would effectively done by you (Przemek), and
your POV and concerns are perfectly understandable to me. If
you won't work on it, I see not much point having it in our
repository. To me the code looks quite complicated to even
cleanup, so while I could contribute in this area, I'm not sure
it would give huge results/benefits in this case, since the
problems to solve are much deeper.

So overall, simply having a copy of LetoDB inside our contrib
area doesn't have a point.

However sad this is. I'd be also happy to have such "NETRDD",
but maybe it should be reached by some other means.

[ I'd be even happier with a GTNET driver though ;) Which,
seems much simpler to implement and even more efficient, but
only for CUI apps. ]

Brgds,
Viktor



Response by Pritpal Bedi

Date: Fri, 2 Oct 2009 14:47:39 -0700 (PDT)
From: Pritpal Bedi <bedipritpal@hotmail.com>

Hello Przemek

Przemyslaw Czerpak-2 wrote:
>
> This is what I can see after rather short code look up mostly on
> client side.
> In summary to resolve these problems we will have to rewrite most
> of current LetoDB code dropping xHarbour and old Harbour support.
> I haven't analyzed this code very deeply but seems that we can keep
> only very small part of existing LetoDB code.
> For me it is much easier to create new project with such functionality
> from scratch then trying to update current LetoDB code. For sure it
> will take less time and I will make much less mistakes so I do not
> find big motivation to work on it. I know myself and if I start to
> update it then I'll end with completely rewritten code but using the
> same project name and original authors' copyrights.
>
Absolutely correct assertion.
 

> I do not need such remote server for my own use - all my applications
> are executed fully on the server side so I do not want to reduce it
> to ADS like level.
>

The whole Harbour community knows about you and
your capabilities, and know it well.

Having said that, whatever you have contributed to Harbour till date
may be comprising a small part of your projects, but still you contributed,
contributed for the sake of creativity and a with a great sense to provide
a stable platform to your fellow developers, and we all feel indebted
for it, thank you.

> In the past I started to work on NETRDD and I documented the
> server and client part and defined basic communication protocol
> but so far I haven't time to finish it. Seeing what happens with
> my code in xHarbour I also do not find big motivation to finish
> it and public as free OpenSource project but I also do not have
> any precise plans about commercial releasing. Just simply I haven't
> taken the decision yet. Maybe I'll finish it and release as close
> source binary library which can be freely used with Harbour but
> only with applications which do not use any commercial libraries.
> Or maybe I'll invest much more time in it and try to write full
> RDBMS with transactions, SQL support and query optimizer and
> release it as commercial project. I do not know yet but I think
> I should inform you about it because maybe in the future I will
> not be on neutral position here so you should take your really
> own decision about LetoDB future in Harbour contrib code and my
> opinion and above text is only small help which you can ignore.
>

We know your concerns and which are right ones.
But still community is looking at you with great aspirations and
hopes to realize the dream of a remote rdd, which, only and only
you can bring to fruitation. It does not matter how you would
like to publish it, free open-source, free closed-source, or,
commercial open/closed-source, but it MATTERS that you just
start it and let us make optimistic about our futures.

Again, please note that, Harbour community is indebted
to your all great contributions...

Regards
Pritpal Bedi

 

Harbour MiniGUI 1.7 Extended Edition (Build 74) Released on 30th Sept 2009

CCH : From the HMG Extended Forum


Hi All,

The Harbour MiniGUI 1.7 Extended Edition (Build 74) setup is published at the following URL:

http://hmgextended.com/files/CONTRIB/hmg-1.7-74-setup.zip

and the Lite build 74 at the following URL:

http://hmgextended.com/files/CONTRIB/hmg-1.7-74-setup-lite.zip

There is the following changelog for this build below:

2009/09/30: Build 74 (HMG 1.7 Extended Edition) Published.
* Fixed: Typo with static declaration of the function FLD_PageInfo in the source\c_folder.c.
Reported by Francek Prijatelj <francek.prijatelj@siol.net>
* Fixed: Problem with ONCLICK, ON CLICK clause of Label control in the header file.
Reported by Rene Koot <rene@plantenkennis.com>.
Contributed by Grigory Filatov <gfilatov@freemail.ru>
(see demo in folder \samples\Basic\Label)
* Updated: Socket library v.1.07:
- Fixed: problem with hb_xgrab zero bytes allocation
Contributed by Mitja Podgornik <yamamoto@rocketmail.com>.
(see socket.c in folder \Source\Socket)
* Updated: HBPrinter library (see source in folder \source\HbPrinter):
- Fixed: Closing of Preview was destroyed the modal status of the previous window.
Reported by Krzysztof Stankiewicz <ks@nsm.pl>.
Contributed by Grigory Filatov <gfilatov@freemail.ru>
- Updated: Polish language translation.
Contributed by Krzysztof Stankiewicz <ks@nsm.pl>.
* Updated: Adaptation FiveWin Class TSBrowse 7.0 in HMG:
- Fixed: service of key Esc in the Append mode;
- Fixed: improved Scrollbar working;
- Fixed: assigned but unused variables.
Contributed by Janusz Pora <januszpora@onet.eu>
* Updated: HbSQLite3 library source code (see in folder \Source\HbSQLite3):
- updated for using SQLITE3 version 3.6.18
Contributed by Grigory Filatov <gfilatov@freemail.ru>
(see demos in folders \samples\Advanced\SQLITE and \samples\Advanced\SQLITE_2)
* Updated: HMG_QHTM library (see source in folder \Source\QHTM).
Contributed by Vladimir Chumachenko <ChVolodymyr@yandex.ru>
(look at changelog.txt in folder \Source\QHTM)
* Updated: Harbour Compiler 2.0.0beta3 (SVN 2008-09-28 22:27).
Contributed by Grigory Filatov <gfilatov@freemail.ru>
(look at ReadMe.txt in folder \harbour and WhatsNew.txt in folder \harbour\doc)
* Updated: HMGS-IDE v.0.9.4.1. Project Manager and Two-Way Visual Form Designer.
Contributed by Walter Formigoni <walter.formigoni@uol.com.br>
(look at changelog.txt in folder \Ide)
* New: 'Grid Color' sample. Contributed by Grigory Filatov <gfilatov@freemail.ru>
(see demo in folder \samples\Advanced\GridColor)
* Updated: 'Joint usage of QHTM & SQLite3' sample:
- added web-form support.
Contributed by Vladimir Chumachenko <ChVolodymyr@yandex.ru>
(see in folder \samples\Advanced\qhtm_2)
* Updated: 'System services' sample.
Problem was reported by Paul Schlicher <paulschlicher@yahoo.com>
Contributed by Grigory Filatov <gfilatov@freemail.ru>
(see in folder \samples\Advanced\WMI_Service_
2)

This release of MiniGUI is considered stable and ready for production use.

Remark: There is the following description in the curreent Harbour changelog:

2009-09-02 14:08 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbcomp.h
* harbour/include/hbcompdf.h
* harbour/source/compiler/hbmain.c
* harbour/source/compiler/genc.c
* harbour/source/compiler/genhrb.c
+ added support for compiling multiple .prg modules into single
compilation unit with repeated static or init/exit functions
with the same name.
Now Harbour compiler compiling .prg code from different .prg modules
included by @.clp or by SET PROCEDURE TO ... / DO ... [ WITH ... ]
works exactly like Clipper. It supports separated file wide definitions
for each compiled .prg module when -n switch is used and allows to
use static or init/exit functions/procedures with the same names but
in different modules.
It resolves incompatibility often reported by [x]Harbour users.
Now it's not longer necessary to update existing Clipper code.
@.clp files and SET PROCEDURE TO ... / DO ... [ WITH ... ] are
fully functional like in Clipper.
AFAIR it was the last unintentional incompatibility with Clipper.

Your comments are welcome!

--
Best Regards,
Grigory Filatov
[MiniGUI Team]