hmg-4 Changelog

[mrduck]

Code: Select all

2010-12-06 21:00 UTC-0300 Carlos Britos ( <bcd12a(a_t)yahoo.com.ar> )
  * include/hmg.ch
    ! changed grid defines, since are not used in another code than grid.prg
      and there, are defined in this way.
      #define GRID_JTFY_LEFT     0  //  ex LBL_LEFT    0
      #define GRID_JTFY_RIGHT    1  //  ex LBL_RIGHT   2
      #define GRID_JTFY_CENTER   2  //  ex LBL_CENTER  1
  * source/grid.prg
    - deleted #defines

Carlos, GRID_ defines can be used in usercode...

[mrduck]

Code: Select all

2010-12-07 23:35 UTC+0100 Francesco Perillo (<fperillo at gmail.com>)
  * include/hmg.ch
    * sorted the one-liner definitions PLEASE ADD IN ALPHABETICAL ORDER !
    * added some new one-liner definitions added by Luigi

2010-12-07 23:05 UTC+0100 Francesco Perillo (<fperillo at gmail.com>)
  * hmg.hbp
    * removed errorsys.prg, it is faulty, read inside the file
  * source/combobox.prg
  * source/listbox.prg
    * moved assignment of onchange AFTER setting the value,
      compatible with HMG3
  * source/window.prg
    * for better compatibility with HMG3 windows STANDARD doesn't go
      modal, but return control to the calling program immediately
  * include/hmg.ch
    * changed toolbar definition that preprocessor mishandled

[Rathinagiri]

Super! Thanks a lot Francesco. I am now working on virtual grid (using TableView).

[mrduck]

Super! Thanks a lot Francesco. I am now working on virtual grid (using TableView).

Hi Rathinagiri,
me and Luigi are cooperating on a small test project: he writes some form code in HMG-3 and then we try to compile in HMG-4 and try to get the same results.... so we discovered that compatibility layer is incomplete...

we'd like to make a proposal.
hmg.ch contains only #define valid for everything.
if you write your code using "with object...." you only need that file


hmg4.ch contains the compatibility layer (and includes hmg.ch) for extended syntax. please beware ! there are 2 or 3 different alternate syntax:

1a)
DEFINE WINDOW oForm TYPE WND_MAIN // all on one line

1b)
DEFINE WINDOW oForm ;
TYPE WND_MAIN // on two lines but it actually is like the one above, it's one line for the preprocessor

2)
DEFINE WINDOW oForm
TYPE WND_MAIN // on two lines and 2 lines for the preprocessor...

3) only for some objects
@ .....

type 1a, 1b (and 3) need complex preprocessor directives:
#xcommand DEFINE WINDOW <o> [TYPE <x>] => with object <o> := new():window() ; [ :nType := <x> ]
and there may be different variants (have a look at different DEFINE TOOLBAR)

type 2 need separate directives:
#xcommand DEFINE WINDOW <o> => with object <o> := new():window()
#xcommand TYPE <x> => :nType := <x>

I'd call EXTENDED SYNTAX type 1 and 3, ONELINER SYNTAX type 2...

We also found a problem: when using extended syntax, if the converted code contains the IF statement, preprocessor stops translating... I'll post to harbour developer list to see if a problem of the developer or if we want to do things not possible to do


What I ask now to all core developers:
for the code you have developed, please have a look if all the EXTENDED and ONELINER SYNTAX are present.
If present but not implemented (you only save the value but do nothing with it) please issue a msginfo() or a hb_tracestring() so that developers using that feature know immediately that it won't work...

Luigi created some more #xcommand I will commit later today.

[Rathinagiri]

Thanks a lot Francesco.

I commonly use the syntax 2 you specified.

I am sure we have to clean up hmg.ch. I thought that all the syntaxes are working well. We have to test one by one.

[mrduck]

2011-08-12 00:54 UTC+0200 Francesco Perillo ( fperillo (at) gmail.com )
* source/hmgapp.prg
* Changed hmgapp() to be a real singleton

some more info on the second part of this post (viewtopic.php?p=17437#p17437)


TO ALL HMG4 DEVs

Please keep posting commit messages here. It's a quick way to know when a commit was done and a place where, if necessary, add some notes.

Please no "thank you" message in this thread, should be kept strictly technical.

[mrduck]

2011-08-12 09:04 UTC+0200 Francesco Perillo ( fperillo (at) gmail.com )
* samples/agenda
* ported sample "agenda" from hmg3 to show that it is possible
to port with just a few changes
port is not completed and there are a few glitches that are in
hmg4 and not in the port (doubleclick on a name looking at the
buttons at the bottom and then click on Cancelar)
resource file is not ported yet


Any volunteer to traduce the text into english ?

[mrduck]

2011-08-21 22:04 UTC+0200 Francesco Perillo ( fperillo (at) gmail.com )
+ include/hmg3.ch
* added some HMG3 definitions, they are needed only on legacy code
that uses lines like ONCLICK window.widget.setfocus
This file is included if HMG3 is defined (ex: -DHMG3 in hbmk.hbm)
This file contains the #translate code for the above program
lines... I converted some from HMG3 (domethod/get-setproperty)
to HMG4 style window:widget:setfocus() but some are still to
be converted
* include/hmg.ch
* added some missing HMG3 definitions, some are implemented, some are
just placeholders just to be able to compile and test legacy HMG3
code
* source/basic.prg
* source/control.prg
* source/virtualwindow.prg
* source/window.prg
* removed aControls
* removed the code that modified the class at runtime since it was
really dangerous
* added an hash/on error based way to safely simulate runtime change
of the class
* source/hmgapp.prg
* removed aControls - since it is a singleton I kept (for the moment)
the runtime modification of the class
* source/combobox.prg
* event onChange activated only when object fully created
* source/splitbox.prg
* code to be verified and a couple of methods should be changed to
be active only when the object is fully created
* source/toolbar.prg
* added missing default Font
* source/window.prg
* overloaded :Visible(). Windows should not be shown during create
period since its children widgets won't be shown and need explicit
show() themselves (more difficult to achieve)

[mrduck]

2011-08-22 23:44 UTC+0200 Francesco Perillo ( fperillo (at) gmail.com )
* source/basic.prg
* source/control.prg
* Using QPalette and Color Group and Color Roles to change fore/back
colors for active and disabled widgets. May need some
refinements. Removed the use of stylesheets and some strange code
in ENABLED method.
Now Qt takes care of the color to use.
* source/button.prg
* overloaded FLAT method to use Qt primitive and not stylesheet
FLAT is used in other widgets and they use the method contained
in BASIC that uses stylesheet.
* source/statusbar.prg
* changed QFrame style to force RAISED labels, the previous was
dependent on operating system or application GUI style. Statusbar
items on everything demo were not shown raised on Windows XP.
* samples/label/demo_6.prg
+ little demo to test RAISED labels
* source/virtualgrid.prg
* added the current line parameter to dynamic color codeblock so that
it may know which row we are currently painting.
* samples/everything/demo_1.prg
* browse and virtualgrid have different dynamic color codeblocks due to
change to virtualgrid
* include/hmg.ch
* removed some HMG3 compatibility definitions that are now in its
dedicated include file (include/hmg3.ch)
* samples/agenda/agenda.prg
* code reverted to pristine HMG3 status, so to put in use the new
definitions in hmg3.ch.
* added resource files. Actually icons work but not the avi file.
* samples/agenda/hbmk.hbm
* added define to force include of HMG3 compatibility layer
+ samples/agenda/agenda.hbp
+ samples/agenda/agenda.qrc
* added resource file. Now it is necessary to compile using hbp file

[l3whmg]

Hi friends.

Code: Select all

2011-08-29 20:45 UTC+0100 Luigi Ferraris ( <luigi at l3w.it> )
  ! source/window.prg
  ! source/virtualwindow.prg
    ! fixed how to retrieve object from parent. Take a look to
      "::oParent:GetData(..." instead of "::oParent:&cObjName".
    ; I think the problem comes from XerrorHandler because remove the
      first "_" and within classes syntax create problem. It's not a
      great technical documentation: sorry.

  * source/hmgapp.prg
    + added oQtLocale, nCountry, nLanguage, bOnStartUp, cPlugInDir, cStyle,
      cPlugInDir, oQtResource, aResources
    * aligned HMG4 parental system
    ! Country method can be used to assign a value but before using Start()
    ! Language method can be used to assign a value but before using Start()
    * little restyle

  * source/globshared.prg
    - removed s_oQtRes, s_aResources, s_cStyle, s_nCountry, s_nLanguage,
      s_bOnShutDown, s_bOnStartUp, s_cPlugInDir, s_oQtLocale
      These variables have become useless (here) since it was introduced
      the singleton. They are replaced with other into HMG_HMGAPP class.

  * source/basic.prg
    + added GetData( cName ) method to retrieve object; this method
      call __GetItem.
      
  ; about parent management methods I think it would be good to reduce
    the number of methods and standardize the names. For exmaple:
    AddData real __AddItem can be ChildAdd,
    DelData real __RemoveItem can be ChildRemove
    GetData real __GetItem can be ChildGet
    and so on.
    
  * Changelog
    * errata corrige "s_oDefalutParent" changed to "s_oDefaultParent"
      many thanks to Itamar to have notice my mystake.

I do a test about "SET INTERACTIVE...." and IMHO it doesn't work properly. When you run the "svn\samples\window.close\demo_1.prg", then you click on the 'Open Standard Window' button and then you click on the 'Close Window' button you will receive the message "bye?" about "OnInteractiveClose": I think this is wrong. The INTERACTIVE options must work with [X] button not with normal button within form: isn't it or my mistake?
Somewhere on internet I read about [X]: QT handles this as normal close event. To catch [X] there are different(?) solutions, but I believe that at this time would be good to postpone the implementation.
On the other hand, I think it's not a good idea to connect the "Release" method to the CloseEvent; Release method can do some test but at least must execute ::oQtObject:close() and can't be the final slot.

Best regards