Wednesday, March 9, 2011

HMGS-IDE 1.0.7 Released on 9th March 2011

CCH: From the HMG Extended Forum

Hi All,

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

Whatsnew by Walter Formigoni:
2011-03-07: version 1.0.7
*Added: in menu delete special control DROPDOWN MENU.
*Added : in controlorder option to show or not Label control. Requested by Sudip <sudipb001@gmail.com>
*Changed: in loadform of control TSBROWSE with complete fields.
*Added: copy controls. Requested by Sudip <sudipb001@gmail.com>
*Changed : in controls , selecting a control will be copied to form until is unchecked by DeSelect button.

You can update this build via clicking 'Update' menuitem in the main
menu 'Help'.

--
Kind Regards,
Grigory Filatov
[MiniGUI Team]

Monday, March 7, 2011

Habour 2.1 now supports Alert() mapped to MessageBox()

Great news ! In scanning the ChangeLog dated 22nd Feb 2011 that came with HB2.1, i found this gem


2011-01-10 20:02 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/src/rtl/gtgui/gtgui.c


+ added basic support for redirecting ALERT() to MessageBox() in
MS-Windows GTGUI builds. Please remember that MessageBox() supports
only few predefined buttons so it's not possible to show all user
options. Anyhow it should be enough to present error messages
generated by default error handler.


I am sure you know what this means to Clipper programmers migrating their codes to Harbour :-)

Just tested Alert() as in :-

nchoice := Alert( 'Print or Display &mreptname', { 'PRINT', 'DISPLAY', 'CANCEL' } )

Observations
============
1. Can handle up to 3 buttons. If a 4th button is added to the array of choices, only 1 button will show up

2. No Window title
3. No Icon

Adding MsgInfo() Functionality to a Harbour app

CCH : Assuming that you want a simple Alert() replacement and do not want to add harbour-compatible libs such as gtWVG, HMG or Minigui, you may want to check out this piece of code by Vailton Renato posted recently on the harbour-users Google group.

/*
* An MsgInfo() implementation using hbwin library.
* 06/03/2011 - 21:56:45
*
* COMPILE: hbmk2 msginfo1.prg -run -lhbwin
*/
#include "hbwin.ch"

FUNCTION MAIN()
? MsgInfo( "This is a single test" )
RETURN nil

FUNCTION MSGINFO( cText, cTitle )
RETURN WAPI_MESSAGEBOX( 0, cText, cTitle, WIN_MB_ICONQUESTION )

Regards,
Vailton Renato

Friday, March 4, 2011

Harbour/xharbour Diff (4/57) - HASH ARRAYS by Przemyslaw Czerpak

Both compilers have support for hash arrays. They are similar to normal arrays but also allow to use non integer values as indexes like string, date, non integer number or pointer (in Harbour) items.

They can be created using => for list of keys and values enclosed
inside {}, f.e.:
hVal := { "ABC" => 123.45, ;
100.1 => date(), ;
100.2 => 10, ;
100 => 5, ;
date()-1 => .t. }
and then items can be accessed using [] operator, f.e.:
? hVal[ "ABC" ] // 123.45
? hVal[ 100 ] // 5
? hVal[ date()-1 ] // .t.
? hVal[ 100.2 ] // 10
? hVal[ 100.1 ] // date()

By default hash items in both compiler support automatic adding new elements
on assign operation. It can be disabled using one of hash item functions.
Harbour has additional extension which allows to enable autoadd with default
values also for access operation and reference operator. It also supports
well passing hash array items by reference and has some other minor
extensions.

xHarbour does not support autoadd on access or reference operations and
passing hash array items by reference does not work (see passing array and
hash item by reference).

Both compilers have set of functions to make different operations on hash
arrays which give similar functionality. In Harbour they use HB_H prefix
(f.e. HB_HSCAN()) in xHarbour H prefix (f.e. HSCAN())

xHarbour has additional functionality which can be enabled for each hash
array using HSetAACompatibility() function. It's an index where is stored
information about the order in which items were added to hash array and
set of functions with HAA prefix to operate on hash array items using this
index instead of real position in hash array, i.e. HAAGETVALUEAT() which
works like HGETVALUEAT().

In Harbour such functionality also exists and it's enabled by HB_HKEEPORDER() function but the internal implementation is completely different. Harbour does not emulate associative arrays by special index which keeps assign order but it uses real natural order in hash array. It means that associative array indexes are equal to regular hash indexes so it does not need any translation between them and Harbour users can use regular hash array functions for associative array indexes. So separated functions for accessing by other index are not necessary. The Harbour implementation is also more efficient because it does not introduce linear index updated each time new key is added to hash array.

Harbour emulates HAA*() xHarbour functions in XHB library but only for
compatibility with existing xHarbour code.

HMGS-IDE 1.0.6.2 Released on 4th March 2011

CCH: From the HMG Extended Forum

Hi All,

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

Whatsnew:
2011-03-03: version 1.0.6.2
*Added : ON DROPFILES event management. Requested by Jaroslav Janik . Contribution by Grigory Filatov

You can update this build via clicking 'Update' menuitem in the main
menu 'Help'.

--
Kind Regards,
Grigory Filatov

Wednesday, March 2, 2011

Harbour/xharbour Diff (3/57) - EXTENDED CODEBLOCKS by Przemyslaw Czerpak

Both compilers support compile time extended codeblocks which allow to use statements but with a little bit different syntax. Harbour uses standard Clipper codeblock delimiters {}, f.e.:

      ? eval( { | p1, p2, p3 |
                ? p1, p2, p3
                return p1 + p2 + p3
              }, 1, 2, 3 )

and xHarbour <>, f.e.:
      ? eval( < | p1, p2, p3 |
                ? p1, p2, p3
                return p1 + p2 + p3
              >, 1, 2, 3 )

In Harbour extended codeblocks works like nested functions and support all functions attributes, f.e. they can have own static variables or other declarations which are local to extended codeblocks only and do not effect upper function body.

In xHarbour the compiler was not fully updated for such functionality and extended codeblocks were added to existing compiler structures what causes that not all language constructs work in extended codeblocks and creates a set of very serious compiler bugs, f.e., like in this code with syntax errors but which is compiled by xHarbour without even single warning giving unexpected results at runtime:

      #ifndef __XHARBOUR__
         #xtranslate \<|[]| => {||
         #xcommand > [<*x*>]       => } 
      #endif
      proc main()
         local cb, i
         for i:=1 to 5
            cb := <| p |
                     ? p
                     exit
                     return p * 10
                  >
            ?? eval( cb, i )
         next
      return

It's possible to create many other similar examples which are mostly caused by missing in the compiler infrastructure for nested functions support.

This can be fixed if someone invest some time to clean xHarbour compiler.

Tuesday, March 1, 2011

Harbour/xharbour Diff (2/57) -NEW LANGUAGE STATEMENTS by Przemyslaw Czerpak

1. FOR EACH 
 
Harbour support all xHarbour functionality and it offers also additional
   features which are not available in xHarbour.
   a) it allows to iterate more then one variable
         FOR EACH a, b, c IN aVal, cVal, hVal
            ? a, b, c
         NEXT
   b) it allows to set descending order by DESCEND flag, f.e.:
         FOR EACH a, v IN aVal, cVal DESCEND
            ? a, b
         NEXT
   c) it has native support for hashes:
         FOR EACH x IN { "ABC" => 123, "ASD" => 456, "ZXC" => 789 }
            ? x, "@", x:__enumKey()
         NEXT
   d) it allows to assign string items, f.e.:
         s := "abcdefghijk"
         FOR EACH c IN @s
            IF c $ "aei"
               c := UPPER( c )
            ENDIF
         NEXT
         ? s      // AbcdEfghIjk
   e) it gives OOP interface to control enumerator variables what
      is very important when more then one variable is iterated or
      when FOR EACH is called recursively, f.e.:
         hVal := { "ABC" => 123, "ASD" => 456, "ZXC" => 789 }
         FOR EACH x IN hVal
            ? x:__enumIndex(), ":", x:__enumKey(), "=>", x:__enumValue(), ;
              "=>", x:__enumBase()[ x:__enumKey() ]
         NEXT
   f) it gives very flexible OOP mechanism to overload FOR EACH behavior
      for user define objects adding to above enumerator methods also
      __enumStart(), __enumStop(), __enumSkip() methods what allows to
      implement many different enumeration algorithms depending on used
      data
   g) it does not have any hardcoded limitations for recursive calls
      (it's limited only by available memory and HVM stack size), f.e.:
         proc main()
            p( 0 )
         return
         proc p( n )
            local s := "a", x
            ? n
            if n < 1000
               for each x in s
                  p( n + 1 )
               next
            endif
         return
   In xHarbour there is function HB_ENUMINDEX() which is supported by
   Harbour in XHB library.

2. WITH OBJECT / END[WITH]3. SWITCH / [ CASE / [EXIT] / ... ] OTHERWISE / END[SWITCH]4. BEGIN SEQUENCE [ WITH  ]
   In Harbour it does not have any hardcoded limitations for recursive
   calls (it's limited only by available memory and HVM stack size), f.e.:
      proc main()
         p( 0 )
      return
      proc p( n )
         ? n
         if n < 1000
            with object n
               p( n + 1 )
            end
         endif
      return
   It also uses OOP interface just like FOR EACH, so it's possible to
   use :__withObject() to access / assign current WITH OBJECT value.
   In xHarbour there are functions HB_QWITH(), HB_WITHOBJECTCOUNTER()
   and HB_RESETWITH() which are supported by Harbour in XHB library.


   In Harbour it uses jump table with predefined values what gives
   significant speed improvement in comparison to sequential PCODE
   evaluation just like in DO CASE statements.
   In xHarbour SWITCH does not use such jump table and generated
   PCODE is similar to the one used for DO CASE or IF / ELSEIF
   and only the main switch value calculation is optimized and
   reused for all statements so speed improvement is relatively
   small.
   In xHarbour instead of OTHERWISE the DEFAULT clause is used.
   As SWITCH values Harbour supports integer numbers and strings, f.e.:
      switch x
         case 1         ; [...]
         case 10002     ; [...]
         case "data"    ; [...]
         otherwise      ; [...]
      endswitch
   xHarbour supports only integer numbers and one character length strings
   like "A", "!", "x", " ", ...


   [ RECOVER [ USING  ] ]
   [ ALWAYS ]
   END SEQUENCE

   It's unique to Harbour. In xHarbour limited version of above statement
   exists as:
      TRY
      [ CATCH [] ]
      [ FINALLY ]
      END
   TRY gives exactly the same functionality as:
      BEGIN SEQUENCE WITH { |e| break(e) }

With the exception to SWITCH implementation, in all other statements
described above, xHarbour causes performance reduction in PCODE evaluation
even if user does not use them at all. In Harbour they are implemented in
different way which does not cause any overhead and slowness for other code. 
 
More at http://harbour-project.svn.sourceforge.net/viewvc/harbour-project/trunk/harbour/doc/xhb-diff.txt

Welcome to Clipper... Clipper... Clipper


In 1997, then using Delphi 3, I had already created 32-bits Windows applications for HRIS, ERP and CRM. In 2007, using Ruby on Rails, an AJAX powered CRM site running on Apache & MySQL was created and I am now using Visual Studio .Net 2008 to create web-based projects and Delphi 7 for Win32 applications using SQL2005 & DBFCDX.

So, why then am I reviving the Original Clipper... Clipper... Clipper via a Blog as CA-Clipper is a programming language for the DOS world ? Believe it or not, there are still some clients using my mission-critical CA-Clipper applications for DOS installed in the late 80's and up to the mid 90's. This is testimony to CA-Clipper's robustness as a language :-)

With the widespread introduction of Windows 7 64-bits as the standard O/S for new Windows based PCs & Notebooks, CA-Clipper EXE simply will not work and it has become imperative for Clipper programmers to migrate immediately to Harbour to build 32/64 bits EXEs

Since 28th January 2009, this blog has been read by 134,389 (10/3/11 - 39,277) unique visitors (of which 45,151 (10/3/11 - 13,929) are returning visitors) from 103 countries and 1,574 cities & towns in Europe (37; 764 cities), North America (3; 373 cities) , Central America & Caribeans (6; 13 cities), South America(10; 226 cities), Africa & Middle-East (12; 44 cities) , Asia-Pacific (21; 175 cities). So, obviously Clipper is Alive & Well : -)


TIA & Enjoy ! (10th October 2012, 11:05; 13th November 2015)


Original Welcome Page for Clipper... Clipper... Clipper

This is the original Welcome Page for Clipper... Clipper... Clipper, which I am republishing for historical and sentimental reasons. The only changes that I have made was to fix all the broken links. BTW, the counter from counter.digits.com is still working :-)

Welcome to Chee Chong Hwa's Malaysian WWW web site which is dedicated to Clipperheads throughout the world.

This site started out as a teeny-weeny section of Who the heck is Chee Chong Hwa ? and has graduated into a full blown web site of more than 140 pages (actually hundreds of A4 size pages) ! This is due to its growing popularity and tremendous encouragements from visiting Clipperheads from 100 countries worldwide, from North America, Central America, Caribbean, South America, Europe, Middle-East, Africa and Asia-Pacific. Thanx Clipperheads, you all made this happen !


What is Clipper ?

You may ask, what is this Clipper stuff ? Could Clipper be something to do with sailing as it is the name of a very fast sailing American ship in the 19th century ?

Well, Clipper or to be precise, CA-Clipper is the premier PC-Software development tool for DOS. It was first developed by Nantucket Corporation initially as a compiler for dBase3+ programs. Since then, CA-Clipper has evolved away from its x-base roots with the introduction of lexical scoping & pre-defined objects like TBrowse. As at today, the most stable version ofClipper is 5.2e while the latest version, 5.3a was introduced on 21 May 1996.

As at 11th November, 1996, an unofficial 5.3a fixes file was made available by Jo French. See the About CA-Clipper 5.3a section for more details. BTW, Jo French uploaded the revised 5.3a fixes file on 20th November, 1996.

Latest News

The latest news is that CA has finally released the long-awaited 5.3b patch on 21 May, 1997.

For 5.3b users, you must a take a look at Jo French's comments on unfixed bugs in 5.3b.

BTW, have you used Click ? If you're a serious Clipperprogrammer and need an excellent code formatter, Click is a natural choice. How to get it ? Simple, access Phil Barnett's site via my Cool Clipper Sites.

32-bits Clipper for Windows ?

Have you tried Xbase ++ ? Well, I have and compared to Delphi (my current Windows programming tool of choice), I'm still sticking to Delphi.

Anyway, you should visit the Alaska Home Page. Give it a chance and then draw your own conclusions !.

The Harbour Project

Is this the future of Xbase ? Take a look at at the Harbour Project

You are Visitor # ...

According to counter.digits.com, you are visitor since 3 June 1996.

If you like or dislike what you see on this website, please drop me a line by clicking the email button at the bottom of this page or better still, by filling out the form in my guest book. If you are not sure what to write,click here to take a look at what other Clipperheads have to say.