HMG 3.3.1 (Stable) Released

File Name: HMG.3.3.1.exe
File Size: 46.91 MB
Date: 15. July 2014

Description:

-HMG 3.3.1 (Stable) 2014/07/15

– Updated to latest Harbour Nightly Build (2014-07-15)

– New property in Label control

– NoPrefix

– New New property in DatePicker control

– FORMAT <cFormatDate> (see demo)

– New Now all controls (Button, CheckButton, ToolBarButton, ComboBox, Grid, Tab, Tree, Menu, etc) loaded images: BMP, GIF, TIF, JPG and PNG

– New Now all controls (Button, CheckButton, ToolBarButton, ComboBox, Grid, Tab, Tree, Menu, etc) support the NOTRANSPARENT property

– New Grid control support the NOTRANSPARENTHEADER property

– New Print images in formats: BMP, GIF, JPG, TIF, WMF, EMF, CUR and PNG.

- @ <nRow> , <nCol> PRINT IMAGE <cImageFileName> | <cImageResourcename>
WIDTH <nWidth>
HEIGHT <nHeight>
[ STRETCH ]
[ TRANSPARENT ]
[ TRANSPARENTCOLOR anTransparentColor ]

– New functions for read Keyboard and Mouse (see doc)

– SET CONTROL <ControlName> OF <FormName> ONKEYEVENT <FuncName> | NIL

– SET CONTROL <ControlName> OF <FormName> ONMOUSEEVENT <FuncName> | NIL

– HMG_GetOnKeyControlIndex ( [ @nSubIndex ] ) –> nIndex

– HMG_GetOnMouseControlIndex ( [ @nSubIndex ] ) –> nIndex

– New functions for control edge (see doc)

– SET CONTROL <ControlName> OF <FormName> CLIENTEDGE

– SET CONTROL <ControlName> OF <FormName> STATICEDGE

– SET CONTROL <ControlName> OF <FormName> NOTEDGE

– New Functions:

– GetKeyboardLayoutName()

– ActivateKeyboardLayout()

– GetKeyboardLayout()

– GetKeyboardLayoutList()

– LoadKeyboardLayout ()

– UnloadKeyboardLayout()

– TerminateProcess ( [ nProcessID ] , [ nExitCode ] )

– GetWindowThreadProcessId (hWnd, @nThread, @nProcessID)

– IsWow64Process ( [ nProcessID ] ) –> return lBoolean

– return TRUE if a 32-bit application is running under 64-bit Windows (WOW64)

– return FALSE if a 32-bit application is running under 32-bit Windows

– return FALSE if a 64-bit application is running under 64-bit Windows

– WOW64 is the x86 emulator that allows 32-bit Windows-based applications to running on 64-bit Windows

– New: VirtualKeyboard (see doc)

– VirtualKeyboard.OPEN [ SHOW ]

– VirtualKeyboard.OPEN HIDE

– VirtualKeyboard.Show

– VirtualKeyboard.Hide

– VirtualKeyboard.Release

– VirtualKeyboard.IsRelease

– VirtualKeyboard.IsOpen

– VirtualKeyboard.IsVisible

– VirtualKeyboard.IsMinimize

– VirtualKeyboard.IsMaximize

– VirtualKeyboard.Handle

– VirtualKeyboard.Title [ := | –> ] cTitle

– VirtualKeyboard.Row [ := | –> ] nRow

– VirtualKeyboard.Col [ := | –> ] nCol

– VirtualKeyboard.Width [ := | –> ] nWidth

– VirtualKeyboard.Height [ := | –> ] nHeight

– VirtualKeyboard.FileName –> “OSK.EXE”

– VirtualKeyboard.FullFileName –> GetSystemDir()+”\OSK.EXE”

– Fixed Numeric Textbox bug –> http://hmgforum.com/viewtopic.php?p=34890#p34890

– Fixed bug in Grid control build in 64-bits –> http://hmgforum.com/viewtopic.php?p=34946#p34946

– Fixed bug in FocusedControl Property (reported by Tiampei)

– Fixed Windows problem of overlap between ToolBar Bottom and StatusBar

– HMG IDE

-Fixed when not found the text editor calls notepad.exe of windows (reported by Roberto Lopez)

-Updated Polish language in Unicode (contributed by Marek)

GoVisitBlue324x48

DL_FP_FForumGreen2

DL_OrangeFPFGD400x50

HMG.3.3.1 Portable : ( Patch 3 (Unicode) applied )

HMG.3.3.1 Root.zip 664.53 KB 

HMG.3.3.1 DOC.zip 2.02 MB 
HMG.3.3.1 HARBOUR.zip 21.17 MB 
HMG.3.3.1 hfcl.zip 85.50 KB 
HMG.3.3.1 IDE.zip 1.75 MB
HMG.3.3.1 IDE_ANSI.zip 1.74 MB 
HMG.3.3.1 INCLUDE.zip 207.78 KB 
HMG.3.3.1 lib.zip 588.89 KB
HMG.3.3.1 MINGW.zip 80.84 MB 
HMG.3.3.1 RESOURCES.zip 97.55 KB 
HMG.3.3.1 SAMPLES.zip 9.99 MB 
HMG.3.3.1 SOURCE.zip 697.39 KB 

Coding Guidelines

Coding Guidelines

( by Greg Holmes )

Language Syntax 
The general rule of thumb is: built-in features in lowercase, and custom-written functions in mixed case. 
When specifying the complete syntax of a language element in documentation, the input items, parameters, and so on are referred to using the following symbols:

 Symbol  Description
< >  Indicates user input item
( )  Indicates function argument list
[ ]  Indicates optional item or list
{ }  Indicates code block or literal array
| |  Indicates code block argument list
–>  Indicates function return value
 Repeated elements if followed by a symbol
Intervening code if followed by a keyword
,  Item list separator
|  Indicates two or more mutually exclusive options
@  Indicates that an item must be passed by reference
*  Indicates a compatibility command or function

For example:

    len(<cString>|<aArray>) --> nLength

Metasymbols provide a place holder for syntax elements, and they describe the expected data types. A metasymbol consists of one or more lowercase data type designators followed by a mixed case description. This is known as Hungarian Notation.

 Designator  Description
a  Array
b  Code block
c  Character expression
d  Date expression
exp  Expression of any type
id  Literal identifier
l  Logical expression
m  Memo field
n  Numeric expression
o  Object
x  Extended expression

In this example, dnLower and dnUpper can be either date or numeric:

    @...get...range <dnLower>, <dnUpper>
Filenames and Aliases 
All filenames, in any context, are in upper case. Filenames follow DOS naming conventions (preferably limited to letters, numbers, and the underscore).

    use CUSTOMER
    nHandle := fopen('DATAFILE.DAT')

When referring to specific file types in documentation, include the period.
e.g. “A program is stored in a text file with a .PRG extension.” 
Alias names follow the same conventions as filenames, but are limited to A-Z, 0-9, and the underscore. If a filename begins with a number or contains unusual characters, an alias must be specified when the file is opened or an error will result. 
Note that CA-Clipper does not natively support Windows 95 long filenames, although third-party libraries are available to add the capability.

Fieldnames 
Fieldnames are all uppercase, and always include the alias of the table. Fieldnames may contain underscores, but should not begin with one (because the underscore is generally used to indicate an internal symbol).

    @ 10, 10 say BANKS->BRANCH
    nAge := CUSTOMER->CUST_AGE
Memory Variables 
Memory variables consist of a lowercase type designator followed by a mixed case description (see Hungarian Notation). Although CA-Clipper only recognizes the first 10 characters as unique, variable names may be longer.

    cString := "Hello World"
    nYearlyAverage := CalcYearAvg()

If you use Hungarian Notation for your memory variable names and include the table alias with fieldnames, there will be no conflict between the two.

Commands, Functions, and Keywords 
All built-in commands, functions, and keywords are lowercase. In documentation, the font should be Courier or a similar font. If fonts are not available, then bold or CAPITALIZE the word for emphasis. 
Never use abbreviations — this practice is not necessary with a compiler, although it was common in the early days of dBase (which was an interpreter). 
There should never be a space between the function name and the opening parenthesis. Also, note that the iif() function should never be spelled if().

    replace CUSTOMER->CUSTNAME with cCustName
    nKey := inkey(0)

When specifying commands that have clauses in documentation, separate the keywords with an ellipsis (...) and do not include the to clause, unless it is followed by the file,print, or screen keywords.

    copy...sdf
    set message...center
    @...say...get
Programmer-Defined Functions & Procedures 
These begin with an uppercase letter, followed by mixed case letters as appropriate.

    ? StripBlanks("Hello there, this will have no spaces.")

Function and procedure names may contain underscores, but should not begin with one (they may conflict with internal functions which often start with an underscore). There should be only one return statement per function or procedure, and it should not be indented.

    function SomeFunc (...)
      .
      . <statements>
      .
    return cResult

The return value of a function is not enclosed in parentheses, although parentheses may be used to clarify a complex expression.

    return nValue
    return (nCode * 47) + nAnswer
Preprocessor Directives 
Preprocessor directives are lowercase and are preceded by the # sign.

    #include 'INKEY.CH'

Optionally, you may use single quotes around header files that come with CA-Clipper and double quotes around your own. This convention is purely voluntary, but it helps to distinguish between the two. For example:

    #include 'INKEY.CH'
    #include "MY_APP.CH"

Manifest constants are uppercase.

    #define ESCAPE   27
    if lastkey() == ESCAPE

Pseudo-function names should also be uppercase.

    #define AREA(length, width)   ((length)*(width))
Declarations 
Local variables are grouped according to functionality, and may be declared on one or more lines. The declarations appear as the first code at the beginning of a function or procedure.

    procedure Main ( )
    local nTop, nLeft, nBottom, nRight
    local cOldScreen, cOldColor, nOldCursor

Variables may be declared one per line and accompanied by a description.

    local nCount        // Number of records found.
    local nTotal        // Sum of dollars.

The description can be omitted if better variable names are chosen.

    local nRecordCount
    local nDollarTotal

Variables can be initialized when they are declared, although it is often clearer (and safer) to initialize them immediately before they are used.

    local nRecordCount:=0
    local nDollarTotal:=0
Logicals 
The .T. and .F. are typed in uppercase.
Operators 
The in-line assignment operator (:=) is used for all assignments, and the exact comparison operator (==) is used for all comparisons.

    lContinue := .T.
    nOfficeTotal := nRegionTotal := 0
    lDuplicate := (CUSTFILE->CUSTNAME == cCustName)
    if nLineCount == 4  ...
    if left(PRODUCT->CODE, 3) == left(cProdCode, 3)  ...

Although the compound assignment operators (+=-=*=, etc.) are convenient, they should not be used if readability suffers.

    // The traditional way to accumulate:
    nTotal := nTotal + INVDETAIL->PRICE
    // A good use of a compound assignment operator:
    nTotal += INVDETAIL->PRICE
    // But what does this do?
    nVal **= 2

The increment (++) and decrement (--) operators are convenient, but can lead to obscure code because of the difference between prefix and postfix usage.

    nRecCount++
    nY := nX-- - --nX        // Huh?
Spacing 
Whenever a list of two or more items is separated by commas, the commas are followed by a space.

    MyFunc(nChoice, 10, 20, .T.)

Spaces may be used between successive parentheses.

    DoCalc( (nItem > nTotal), .F. )
    cNewStr := iif( empty(cStr), cNewStr, cStr + chr(13) )

Spaces should surround all operators for readability.

    nValue := 14 + 5 - (6 / 4)

In declarations, often spaces are not used around the assignment operator. This tends to make searching for the declaration of a variable easier.

    local lResult:=.F., nX:=0

Thus, searching for “nX :=” would find the lines where an assignment is made, while searching for “nX:=” would find the declaration line (such as the local above).

Indentation 
Indenting control structures is one of the easiest techniques, yet it improves the readability the most. 
Indent control structures and the code within functions and procedures 3 spaces.

    procedure SaySomething
       do while .T.
          if nTotal < 50
             ? "Less than 50."
          elseif nTotal > 50
             ? "Greater than 50."
          else
             ? "Equal to 50."
          endif
          ...
       enddo
    return

Case statements in a do…case structure are also indented 3 spaces.

    do case
       case nChoice == 1
          ? "Choice is 1"
       case ...
          ...
       otherwise
          ...
    endcase
Tabs 
Do not use tabs in source code — insert spaces instead. Tabs cause problems when printing or when moving from one editor to another, because of the lack of a standard tab width between editors and printers. Typically, printers expand tabs to 8 spaces which easily causes nested control structures to fall off the right-hand side of the page. Commonly, a source code editing program will insert the appropriate number of spaces when the <TAB> key is hit.
Line Continuation 
When a line of code approaches the 80th column, interrupt the code at an appropriate spot with a semicolon and continue on the next line. Indent the line so that it lines up in a readable manner.

    set filter to CUSTFILE->NAME  == 'John Smith  ';
            .and. CUSTFILE->STATE == 'OR'

To continue a character string, end the first line with a quote and a plus sign and place the remainder on the next line. Try to choose a logical place in the string to break it, either at a punctuation mark or after a space.

    @ 10, 10 say "The lazy brown fox tripped over " + ;
                 "the broken branch."
Quotes 
Use double quotes for text that needs to be translated (will appear on the screen), and single quotes for other strings.

    ? "Hello World!"
    cColor := 'W+/B'
    SelectArea('PROP')

This is a simple but extremely effective technique because translation departments often want to see the messages in context (in the source code), so the different quote types indicate which messages are to be translated and which should be left alone.

Comments 
Comments are structured just like English sentences, with a capital letter at the beginning and a period at the end.

    // Just like a sentence.
    /* This comment is longer. As you
       can see, it takes up two lines */

You may encounter old-style comment indicators if you maintain older (Summer’87 and earlier) code.

    && This is an older-style of comment indicator.
    *  The asterisk is also old.

For in-line comments, use the double slashes.

    use CUSTOMER            // Open the data file.
    goto bottom             // The last record.

Note that the ‘//‘ of in-line comments begins at column 40, if possible. This leaves enough room for a useful comment.

Source :  http://www.ghservices.com/gregh/clipper/guide.htm

TAB Control

HMG Tutor 17

Getting Organized (TAB Control)

A TAB control lets organize controls and save form space, grouping the controls in folders.

#include "hmg.ch"
Function Main
DEFINE WINDOW Win_1 ;
   AT 0,0 ;
   WIDTH 400 ;
   HEIGHT 250 ;
   TITLE 'Tutor 17 Tab Test' ;
   MAIN
   DEFINE MAIN MENU
      POPUP "First Popup"
         ITEM 'Change Tab Value' ACTION  Win_1.Tab_1.Value := 2
         ITEM 'Retrieve Tab Value' ACTION  MsgInfo ( Str(Win_1.Tab_1.Value))
      END POPUP
   END MENU
   DEFINE TAB Tab_1 ;
      AT 10,10 ;
      WIDTH 350 ;
      HEIGHT 150
      PAGE 'Page 1'
         @ 50,50 LABEL Label_1 VALUE 'This Is The Page 1'
      END PAGE
      PAGE 'Page 2'
         @ 50,50 LABEL Label_2 VALUE 'This Is The Page 2'
      END PAGE
   END TAB
END WINDOW
ACTIVATE WINDOW Win_1
Return

HMG IDE Basics

HMG-IDE

Harbour MiniGUI Integrated Development Environment is a comprehensive and highly sophisticated project management and form design tool. It is also extremely facilitated to easily use. HMG-IDE has four windows:

  1. Main Window (Control Panel),
  2. Project Browser,
  3. Object Inspector and
  4. Form Design Board.

You may use IDE for project management, for form design purpose or for both.

HMG-IDE Main Window ( Control Panel )

The main window is constituted on a menu bar and a tool box, having many command buttons with descriptive tool tips. This tool box may consider two sections:  project management tools and form design tools. Form design tools are divided into a “main controls” area and a “builders” area.

The project management tools allow you all project based works with interactive manner. This includes building and running projects without complex batch processing and environment configuration tasks. Project management tools buttons are:

Project Management Buttons

Project Browser

The Project Browser window’s tabs: Project Browser Tabs

  1. Modules,
  2. Forms,
  3. Resources,
  4. Reports,
  5. Configuration,
  6. Include and
  7. Tables

You can view, select and inspect all project elements in this window. Whenever you add or exclude a project element (module (program source file), form, resource, report …), IDE automatically updates the project browser.

Object Inspector 

The Object Inspector window is for view and change properties and events of GUI elements in your forms. Object Inspector

You can observe and modify properties and events value of graphical elements of your form in the Object Inspector window.

Form Window

The form window is a chalk board for designing forms and directing its graphical elements. New or existing, when you open a form, this windows also opened by IDE. With only two clicks you can easily place controls on your form: the first on desired button of control in form design tool box and the second one is anywhere in form you like. After placed, you can resize and change its place by dragging.

HMG IDE FormWindow

Controls :

In GUI programming jargon, GUI elements are called as control. HMG offers tons of controls and HMG-IDE successfully supports all of them.

At the beginning you have a form (window) and then you can easily replace any control onto this form. Simply click button of control to used, and then click any place on form to indicate placement (upper left corner) of control.

In short, you can build a complete form by only two clicks for each control. For example, suppose that we want putting an image control on our form; the button of image control is here:

First click this “image” button the toolbar of HMG-IDE, and then click anywhere in the form. This clicked point in the form, will be left upper corner of control; in this case : image.

This isn’t image itself, only a place-holder for image control.

When you placed a control in your form, IDE assign default values to its properties and events.

You can change the placement of control dragging by mouse with upper left corner ( point no: 1) of this place-holder and resize it with lower down corner ( point no: 2 ).

As first placed and whenever you select (click) any control in the form, this control come active in Object Inspector.   And as following on Object Inspector, every control has many properties and events. Since IDE assigned default values to all properties and events of that control, we don’t have learning meaning of all of them, at least at the beginning.

Whenever you change these values interactively on the form, IDE also updates them internally. You can observe and modify them in the Object Inspector window. HMG forms are designed “two way” manner. Saved in a readable format; in fact they are pure HMG source codes, neither binary nor cryptic. You can separately open,  inspect and also modify them. When opened by IDE, they are automatically converted to visual form.

Yes, you can edit .fmg file out of HMG, via any text editor when necessary. But please be careful, some points may be left out standards of IDE, though they have legal syntax.

IDE Toolbar :

IDE Toolbar ( indicated in above image by “Form Design Tools” ) has a button for each control. Every button has its own tool-tip; when mouse cursor keep over a button, tool-tip become visible and say name of this control.

Anyway here long name of all control is here:

Builders :

HMG-IDE has several builders for some relatively complex controls: You can use these features for placing  appropriate controls in your form: