hwgui-developers — Discussing of HwGUI development

Re: [Hwgui-developers] hwgui directories structure

[oleksa <m.o...@uk...>]

Hi!

Can you explain your choice of only SVN?

Regards,
Alexey Myronenko

 --- Оригінальне повідомлення ---
Від кого: "Luiz Rafael Culik" <lu...@xh...>
Дата: 20 червня 2013, 16:10:40

 
> Alex
> 
> Please, no github, stay all hwgui only on SVN
> 
> 
> Regards
> 
> Luiz
> 
> 
> 
> 
> 
> 
> 
> 2013/6/20 Alexander S.Kresin <al...@be...>
> > I prepare sources for uploading them to github, it's a good time to
> > 
> > change the directories structure, if needed. Are there any suggestions ?
> > 
> > 
> > Regards, Alexander.
> > 
> > 
> > ------------------------------------------------------------------------------
> > 
> > This SF.net email is sponsored by Windows:
> > 
> > 
> > Build for Windows Store.
> > 
> > http://p.sf.net/sfu/windows-dev2dev
> > 
> > _______________________________________________
> > 
> > Hwgui-developers mailing list
> > Hwg...@li...
> > https://lists.sourceforge.net/lists/listinfo/hwgui-developers
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> 
> _______________________________________________
> Hwgui-developers mailing list
> Hwg...@li...
> https://lists.sourceforge.net/lists/listinfo/hwgui-developers

Re: [Hwgui-developers] hwgui directories structure

[Luiz R. C. <lu...@xh...>]

Alex

Please, no github, stay all hwgui only on SVN

Regards
Luiz


2013/6/20 Alexander S.Kresin <al...@be...>

> I prepare sources for uploading them to github, it's a good time to
> change the directories structure, if needed. Are there any suggestions ?
>
> Regards, Alexander.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Hwgui-developers mailing list
> Hwg...@li...
> https://lists.sourceforge.net/lists/listinfo/hwgui-developers
>

[Hwgui-developers] hwgui directories structure

[Alexander S.K. <al...@be...>]

I prepare sources for uploading them to github, it's a good time to 
change the directories structure, if needed. Are there any suggestions ?

Regards, Alexander.

Re: [Hwgui-developers] Anothers problems with -DHWG_USE_POINTER_ITEM

[Alexander S.K. <al...@be...>]

  Just few words more about the pointer to long conversion. Windows send 
messages with parameters wParam and lParam, which may be pointers to 
structures or simple numbers, so the conversion using the hwg_ptrulong() 
should be done in those certain places where the message parameter is 
really a number.


Regards, Alexander.

Re: [Hwgui-developers] Anothers problems with -DHWG_USE_POINTER_ITEM

[Alexander S.K. <al...@be...>]

> 
>        This conversion of pointers to numeric values ( HWG_PTRTOULONG()
>     function ), which is used everywhere in the code creates those problems
>     with focus, colors, etc.
>        HwGUI 2.16c is free of this problem, this is one of the reasons why I
>     suggest to get it as a base. It isn't ideal :), but it is much more
>     clean.
> 
> 
> I already agreed with you and it seems to be the only way to have hwgui 
> working good.
> I think that's better to add on a rocky base the new features, than to 
> patch erratically a collapsing building.

   Just to be understood correctly. 2.16c isn't free of problems, 
related to pointers, it's free of those conversion and some other 
issues. It's much more simple to clean it than the current SVN code.

> All the contributions of Basso and Culik since 2.16c could be 
> implemented after purging them of pointers bugs. 

  Not only pointers.

> I'm trying to resume what, after 2.16c, was a patch and what a new feature.
> Maybe applying the introduced patches, before to add the enhancements, 
> could be the right way.

  I've introduced there all patches in .c sources and headers.

Regards, Alexander.

Re: [Hwgui-developers] Anothers problems with -DHWG_USE_POINTER_ITEM

[Maurizio la C. <m.l...@gm...>]

Hi Alex,

2013/6/20 Alexander S.Kresin <al...@be...>

> Przemyslaw Czerpak writes:
>
> >
> > Fatal code quality which begins to be problematic to keep it alive.
> > Nothing amazing but something what has to happen sooner or later.
>
>   This is exactly what I'm talking about last time.
>

And what I was meaning when you came back to hwgui and I told about the
try-and-go growth of the library.


>
> > But it covers only very small subset of problems created by code
> > which converts windows handles and pointers to numeric values and
> > only for Win32. The time shows that it was bad decision because
> > nothing has really changed in HWGUI code in next years.
>
>    This conversion of pointers to numeric values ( HWG_PTRTOULONG()
> function ), which is used everywhere in the code creates those problems
> with focus, colors, etc.
>    HwGUI 2.16c is free of this problem, this is one of the reasons why I
> suggest to get it as a base. It isn't ideal :), but it is much more clean.
>
>
I already agreed with you and it seems to be the only way to have hwgui
working good.
I think that's better to add on a rocky base the new features, than to
patch erratically a collapsing building.
All the contributions of Basso and Culik since 2.16c could be implemented
after purging them of pointers bugs.
I'm trying to resume what, after 2.16c, was a patch and what a new feature.
Maybe applying the introduced patches, before to add the enhancements,
could be the right way.
Regards.
Maurizio


>
> Regards, Alexander.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Hwgui-developers mailing list
> Hwg...@li...
> https://lists.sourceforge.net/lists/listinfo/hwgui-developers
>

Re: [Hwgui-developers] Anothers problems with -DHWG_USE_POINTER_ITEM

[Alexander S.K. <al...@be...>]

Przemyslaw Czerpak writes:

> 
> Fatal code quality which begins to be problematic to keep it alive.
> Nothing amazing but something what has to happen sooner or later.

  This is exactly what I'm talking about last time.

> But it covers only very small subset of problems created by code
> which converts windows handles and pointers to numeric values and
> only for Win32. The time shows that it was bad decision because
> nothing has really changed in HWGUI code in next years.

   This conversion of pointers to numeric values ( HWG_PTRTOULONG() 
function ), which is used everywhere in the code creates those problems 
with focus, colors, etc.
   HwGUI 2.16c is free of this problem, this is one of the reasons why I 
suggest to get it as a base. It isn't ideal :), but it is much more clean.


Regards, Alexander.

Re: [Hwgui-developers] Anothers problems with -DHWG_USE_POINTER_ITEM

[Przemyslaw C. <dr...@po...>]

On Wed, 19 Jun 2013, Maurizio la Cecilia wrote:

Hi,

> I confirm that as soon as I leave HWG_USE_POINTER_ITEM in hbmk2
> scripts, the gets stop working and the buttons don't display the
> icons.
> Striping out the directive all returns working fine, without any
> change to my sources.
> Any hint about what's causing this behaviour?

Fatal code quality which begins to be problematic to keep it alive.
Nothing amazing but something what has to happen sooner or later.
In Win64 all handles are 64bit size values.
Few years ago I was asking for really long time to eliminate all
conversion between pointers and numeric values.
Such hack was strictly bound with Win32 ABI and was more or less
working correctly, i.e. many years ago Alexander asked why windows
handles are sometimes wrongly converted when 32-nd bit is set in
C 'double' values. The answer is trivial: C standard allows to set
overflow value as result when conversion gives signed overflow.
On some platforms like IBM S390 value 0x80000000 is used as 32bit
signed integer overflow result and it's generated by hardware.
In x86 world it can be result of similar conversion if compiler
strictly follow conversion rules, i.e. GCC works in such way and
as workaround I added unsigned casting to eliminate it. You can
see it in itemapi.c[697]:
   #if defined( __GNUC__ )
         return ( long ) ( HB_ULONG ) pItem->item.asDouble.value;
   #else
         return ( long ) pItem->item.asDouble.value;
   #endif
But it covers only very small subset of problems created by code
which converts windows handles and pointers to numeric values and
only for Win32. The time shows that it was bad decision because
nothing has really changed in HWGUI code in next years.
Now it's time for much more serious problems. As I said in Win64 all
handles and pointers are 64bit values so conversions to ULONG or
double strips some significant bits. MS documented such idiotic
conversions in many MSDN examples and haven't fully switched to 64
bit mode to avoid general code cleanup. In all other 64 bit OS-es
I tested address space was intentionally switched to use high 64 bits
to eliminate buggy code which make conversion like HWGUI compiled
without HWG_USE_POINTER_ITEM and now in Linux we do not have bigger
problems with code which was not cleanly written to work with different
sizes of address spaces, just rethink if it was good decision.
In Win64 still a lot of code which was written in buggy way works more
or less correctly. Anyhow MS is releasing next Win64 versions with new
features and keeping 32-bit base address space begins to be seriously
problematic. It's nothing amazing that in current days some apps
allocates address space to map DVD image or sth like that and
it causes that suddenly "perfectly stable application" crushes,
i.e, I have to change my 64bit windows movie player because aggressive
fast forward was causing GPF due to shortage of virtual free addresses
in first 4GB area. Evan if such application works now then it will
stop to work in one of next Win64 versions.
It means that HWGUI developers cannot longer close their eyes for
this problem and have to clean the code.
It also means that switch like HWG_USE_POINTER_ITEM should be removed
because it _HAS_TO_BE_DEFAULT_ to keep this project alive in the future.

> I read about the need to compare with Empty() values and not with 0,
> but a quick look to my sources don't shows this case.

Look for C source which may make lossy conversions to numeric values or
PRG code which expects numeric items as pointer or handles. Or C code
which still uses conversion to numeric values even if HWG_USE_POINTER_ITEM
is set or any other combinations of above which could appear in last
years.
Anyhow it's good to see that you begin to understand how problematic
is fixing the code which was wrongly written for many years.
I hope that it helps to chose some fundamental decisions about
HWGUI future even if they are problematic and exploits so far hidden
bugs in short term.

I also want to ask all of you to use UNICODE windows API. Sooner or
later MS drop ANSI one also for desktop windows just like it made it
for WinCE/Mobile.

HTH.

best regards,
Przemek

[Hwgui-developers] Anothers problems with -DHWG_USE_POINTER_ITEM

[Itamar M. L. J. L. <ita...@gm...>]

Not working hwg_SetColorinFocus(.T.,00000879,49999999).
And the focus of object not working
For example a dialog with BROWSE and GET CLASS the focus SHOWS in two places
at once :(
<ENTER> key not working because two focus, in BROWSE and at the same time
GET.

Best regards,
Itamar M. Lins Jr.

Re: [Hwgui-developers] Bug Hwgui Get Valid

[Maurizio la C. <m.l...@gm...>]

Hi Alex,

Il 19/06/2013 08:56, Alexander S.Kresin ha scritto:
> Itamar M. Lins Jr. Lins writes:
>> The GET with VALID clausule not work.
>>
>> This simple PRG demonstre the problem.
>>
>    Fixed, see the latest Changelog.
>    But I can't promise that all problems, related to using of
> HWG_USE_POINTER_ITEM are fixed and cleaned, because current SVN code is
> messy and a problem may appear in any place.
I confirm that as soon as I leave HWG_USE_POINTER_ITEM in hbmk2 scripts, 
the gets stop working and the buttons don't display the icons.
Striping out the directive all returns working fine, without any change 
to my sources.
Any hint about what's causing this behaviour?
I read about the need to compare with Empty() values and not with 0, but 
a quick look to my sources don't shows this case.

In my apps all the icons on buttons are built with:

       @ c_col, c_row BUTTONEX &cButName CAPTION button[ 2 ] ;
          SIZE ( 4 + Len( button[ 2 ] ) ) * oApp:pxl_x, oApp:pxl_y ;
          ICON HIcon():AddResource( "VB" + button[ 1 ], oApp:pxl_y , 
oApp:pxl_y ):handle ;
          COLOR 0 ;
          ON CLICK b_click STYLE WS_TABSTOP

So, I don't see where is the culprit.

TIA
Maurizio

>
>    Regards, Alexander.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Hwgui-developers mailing list
> Hwg...@li...
> https://lists.sourceforge.net/lists/listinfo/hwgui-developers
>
>

[Hwgui-developers] 2013-06-19 15:13 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

[Przemyslaw C. <dr...@po...>]

2013-06-19 15:13 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * hwgui/hwgui.hbp
  * hwgui/hwgdebug.hbp
  * hwgui/hwguidyn.hbp
    ! fixed dynamic -cflag to work with hbmk2 which do not support
      reverted backslashes as quoting delimiters

best regards
Przemek

Re: [Hwgui-developers] Error HBP files and warnings

[Przemyslaw C. <dr...@po...>]

On Wed, 19 Jun 2013, Itamar M. Lins Jr. Lins wrote:

Hi!

> Please change the line
> {unix}-cflag=´pkg-config --cflags gtk+-2.0´
> to
> {unix}-cflag='pkg-config --cflags gtk+-2.0'
> ´ to '

It does not fix anything. Reverted apostrophes were intentional
and have special meaning in *nixes.
Unfortunately Viktor decided that such standard *nix syntax
should not be supported by HBMK2 directly and removed this
functionality in his last commit to Harbour GIT repository.
I'll commit workaround for it in a while.

best regards,
Przemek Czerpak

Re: [Hwgui-developers] Error HBP files and warnings

[oleksa <m.o...@uk...>]

Hi!

I haven't such error, and what harbour do you use, see warning from Przemyslaw:

    ; WARNING: for -cflag=`pkg-config --cflags gtk+-2.0` in .hbp files
               it's necessary to use HBMK2 from current Harbour devel
               code

Regards,
Alexey Myronenko

 --- Оригінальне повідомлення ---
Від кого: "Itamar M. Lins Jr. Lins" <ita...@gm...>
Дата: 19 червня 2013, 15:28:23

 
> Hi!
> Please change the line
> {unix}-cflag=´pkg-config --cflags gtk+-2.0´
> 
> to
> {unix}-cflag='pkg-config --cflags gtk+-2.0'
> 
> 
> ´ to '
> 
> 
> I get error
> 
> C:\devl\hwgui>hbmk2 hwgui.hbp
> hbmk2: Harbour: Compilando módulos...
> Error F0034  Bad command line option 'cflags'
> hbmk2[hwgui]: Erro: Executando o compilador Harbour (interno): 1
> (c:\hb32\bin\harbour.exe) -n1 gtk+-2.0` source\guimain.prg -n -q0 -w -es2 --cfla
> 
> gs -olib\.hbmk\win\mingw\ -ic:\HB32\include -iinclude
> 
> After change to apostrophe into hwgui.hbp compile fine but show warning.
> 
> C:\devl\hwgui>hbmk2 hwgui.hbp -rebuild
> 
> hbmk2: Harbour: Compilando módulos...
> hbmk2: Compilando...
> ../../../../source/misc.c: In function 'HB_FUN_HWG_RUNCONSOLEAPP':
> ../../../../source/misc.c:869:18: warning: 'hOut' may be used uninitialized in t
> 
> his function [-Wmaybe-uninitialized]
> hbmk2: Criando biblioteca estáticas... lib\libhwgui.a
> 
> 
> More tests...
> 
> 
> Best regards,
> 
> Itamar M. Lins Jr.
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> 
> _______________________________________________
> Hwgui-developers mailing list
> Hwg...@li...
> https://lists.sourceforge.net/lists/listinfo/hwgui-developers

[Hwgui-developers] Error HBP files and warnings

[Itamar M. L. J. L. <ita...@gm...>]

Hi!
Please change the line
{unix}-cflag=´pkg-config --cflags gtk+-2.0´
to
{unix}-cflag='pkg-config --cflags gtk+-2.0'

´ to '

I get error

C:\devl\hwgui>hbmk2 hwgui.hbp
hbmk2: Harbour: Compilando módulos...
Error F0034  Bad command line option 'cflags'
hbmk2[hwgui]: Erro: Executando o compilador Harbour (interno): 1
(c:\hb32\bin\harbour.exe) -n1 gtk+-2.0` source\guimain.prg -n -q0 -w -es2
--cfla
gs -olib\.hbmk\win\mingw\ -ic:\HB32\include -iinclude

After change to apostrophe into hwgui.hbp compile fine but show warning.

C:\devl\hwgui>hbmk2 hwgui.hbp -rebuild
hbmk2: Harbour: Compilando módulos...
hbmk2: Compilando...
../../../../source/misc.c: In function 'HB_FUN_HWG_RUNCONSOLEAPP':
../../../../source/misc.c:869:18: warning: 'hOut' may be used uninitialized
in t
his function [-Wmaybe-uninitialized]
hbmk2: Criando biblioteca estáticas... lib\libhwgui.a

More tests...

Best regards,
Itamar M. Lins Jr.

Re: [Hwgui-developers] Crash hwgdebug HPAINTTAB:AARRAY

[Alexander S.K. <al...@be...>]

Maurizio,

> The clearest way should be to create a git repository with 2.16c as 
> master branch and the current svn as a secondary branch. Then, start to 
> merge into the master branch only the new features whithout regressions 
> or bugs. 

  Sounds good for me.

Regards, Alexander.

Re: [Hwgui-developers] Crash hwgdebug HPAINTTAB:AARRAY

[Maurizio la C. <m.l...@gm...>]

Hi Alexey,
I was meaning to move, at least temporarily (waiting for patching and
merging again into master branch), all but only the newer modules having
some bug or leading to problems.
The clearest way should be to create a git repository with 2.16c as master
branch and the current svn as a secondary branch. Then, start to merge into
the master branch only the new features whithout regressions or bugs.
BR
Maurizio


2013/6/19 oleksa <m.o...@uk...>

>
>
>  --- Оригінальне повідомлення ---
> Від кого: "Maurizio la Cecilia" <m.l...@gm...>
> Дата: 19 червня 2013, 12:37:51
>
>
> > I vote for moving it in contrib folder.
>
> In this way we should move all *Ex to contrib, not only HTabEx.
>
> > BR
> > Maurizio
> >
> >
>
> Regards,
> Alexey Myronenko
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Hwgui-developers mailing list
> Hwg...@li...
> https://lists.sourceforge.net/lists/listinfo/hwgui-developers
>

Re: [Hwgui-developers] Crash hwgdebug HPAINTTAB:AARRAY

[oleksa <m.o...@uk...>]

 --- Оригінальне повідомлення ---
Від кого: "Maurizio la Cecilia" <m.l...@gm...>
Дата: 19 червня 2013, 12:37:51

 
> I vote for moving it in contrib folder.

In this way we should move all *Ex to contrib, not only HTabEx.

> BR
> Maurizio
> 
> 

Regards,
Alexey Myronenko

Re: [Hwgui-developers] Crash hwgdebug HPAINTTAB:AARRAY

[Maurizio la C. <m.l...@gm...>]

Hi Alex,

2013/6/19 Alexander S.Kresin <al...@be...>

> Itamar M. Lins Jr. Lins writes:
> > Error BASE/1004  Message not found: HPAINTTAB:AARRAY
> > Called from ->__ERRRT_SBASE(0)
> > ...
>
>    This was mentioned a week few ago and the following was my answer:
>
> "That's because of different implementation of HTab in 2.16c and in
> current SVN version. I've told here already, that Htab in SVN is
> complicated and buggy, and now it became clear that it isn't compatible
> with an old version. I have no time and desire to dig in new HTab to fix
> it, the only decision for me is to replace it with an 2.16c. We may save
>    current HTab as HTabEx in source/ or in contrib/ directory. Are there
> other suggestions ?"
>

I vote for moving it in contrib folder.


>
> BTW, the more I dig in the current SVN code to find some bugs, the more
> I think, that the best way is to place my 2.16c to SVN or to GIT as a
> new branch and make it a main branch. Some new features from the current
> SVN are there already ( anchors, scrolling, some others ), we may add
> another, which we will consider really useful.
>
>
I agree, you know that from my previous posts.
Git could be another smart step.
jm2c
BR
Maurizio


> Regards, Alexander.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Hwgui-developers mailing list
> Hwg...@li...
> https://lists.sourceforge.net/lists/listinfo/hwgui-developers
>

Re: [Hwgui-developers] Crash hwgdebug HPAINTTAB:AARRAY

[oleksa <m.o...@uk...>]

Hi!

 --- Оригінальне повідомлення ---
Від кого: "Alexander S.Kresin" <al...@be...>
Дата: 19 червня 2013, 10:10:31

> 
> BTW, the more I dig in the current SVN code to find some bugs, the more 
> I think, that the best way is to place my 2.16c to SVN or to GIT as a 
> new branch and make it a main branch. 

Good point to make that.  But,what is good for hwgui svn or git, possible we can try the GIT?


>Some new features from the current  SVN are there already ( anchors, scrolling, some others ), we may add 
> another, which we will consider really useful.
> 
> Regards, Alexander.
> 

Regards,
Alexey Myronenko

Re: [Hwgui-developers] Crash hwgdebug HPAINTTAB:AARRAY

[Alexander S.K. <al...@be...>]

Itamar M. Lins Jr. Lins writes:
> Error BASE/1004  Message not found: HPAINTTAB:AARRAY
> Called from ->__ERRRT_SBASE(0)
> ...

   This was mentioned a week few ago and the following was my answer:

"That's because of different implementation of HTab in 2.16c and in
current SVN version. I've told here already, that Htab in SVN is
complicated and buggy, and now it became clear that it isn't compatible
with an old version. I have no time and desire to dig in new HTab to fix
it, the only decision for me is to replace it with an 2.16c. We may save
   current HTab as HTabEx in source/ or in contrib/ directory. Are there
other suggestions ?"

BTW, the more I dig in the current SVN code to find some bugs, the more 
I think, that the best way is to place my 2.16c to SVN or to GIT as a 
new branch and make it a main branch. Some new features from the current 
SVN are there already ( anchors, scrolling, some others ), we may add 
another, which we will consider really useful.

Regards, Alexander.

Re: [Hwgui-developers] Bug Hwgui Get Valid

[Alexander S.K. <al...@be...>]

Itamar M. Lins Jr. Lins writes:
> 
> The GET with VALID clausule not work.
> 
> This simple PRG demonstre the problem.
> 

  Fixed, see the latest Changelog.
  But I can't promise that all problems, related to using of 
HWG_USE_POINTER_ITEM are fixed and cleaned, because current SVN code is 
messy and a problem may appear in any place.

  Regards, Alexander.

[Hwgui-developers] winprn.prg sample not work

[Itamar M. L. J. L. <ita...@gm...>]

Error BASE/1302  Argument error: HB_TRANSLATE
Called from ->HB_TRANSLATE(0)
Called from source\hwinprn.prg->HWINPRN:PRINTTEXT(279)
Called from source\hwinprn.prg->HWINPRN:PRINTLINE(267)
Called from winprn.prg->MAIN(31)

HwGUI 2.17 Harbour 3.2.0dev (r1306111826)
Date:06/14/13
Time:23:27:36

best regards,
Itamar M. Lins Jr.

[Hwgui-developers] Crash hwgdebug HPAINTTAB:AARRAY

[Itamar M. L. J. L. <ita...@gm...>]

Error BASE/1004  Message not found: HPAINTTAB:AARRAY
Called from ->__ERRRT_SBASE(0)
Called from ../../../tobject.prg->HPAINTTAB:ERROR(0)
Called from ../../../tobject.prg->(b)HBOBJECT(0)
Called from ../../../tobject.prg->HPAINTTAB:MSGNOTFOUND(0)
Called from ../../../tobject.prg->HPAINTTAB:AARRAY(0)
Called from hwgdebug.prg->SETCURRLINE(930)
Called from hwgdebug.prg->SETMODE(636)
Called from hwgdebug.prg->DOCOMMAND(711)
Called from hwgdebug.prg->(b)MAIN(219)
Called from source\hwindow.prg->ONCOMMAND(858)
Called from source\hwindow.prg->(b)HMAINWINDOW(251)
Called from source\hwindow.prg->HMAINWINDOW:ONEVENT(470)
Called from ->HWG_ACTIVATEMAINWINDOW(0)
Called from source\hwindow.prg->HMAINWINDOW:ACTIVATE(426)
Called from hwgdebug.prg->MAIN(290)

HwGUI 2.17 Harbour 3.2.0dev (r1306111826)
Date:06/14/13
Time:23:11:26

[Hwgui-developers] Hwgui bug, Get Valid and hwg_SetColorInFocus() Found :)

[Itamar M. L. J. L. <ita...@gm...>]

Hi!
I, coment  #-cflag=-DHWG_USE_POINTER_ITEM
And works fine.


#
# $Id: hwgui.hbp 2076 2013-06-13 15:37:33Z druzus $
#

-3rd=hbide_version=1.0
-3rd=hbide_type=Lib
-3rd=hbide_title=hwgui
-3rd=hbide_output=hwgui

-inc
-hblib
-olib/hwgui
-n
-q0
-w
-es2
-iinclude

#-cflag=-DHWG_USE_POINTER_ITEM
{unix}-cflag=`pkg-config --cflags gtk+-2.0`

@hwgui.hbm

Best regards,
Itamar M. Lins Jr.

[Hwgui-developers] Bug Hwgui Get Valid

[Itamar M. L. J. L. <ita...@gm...>]

The GET with VALID clausule not work.

This simple PRG demonstre the problem.


/* 2013-06-13 17:37 UTC+0200 Przemyslaw Czerpak */

#include 'hwgui.ch'

Function Main

Local oFont, cTitulo:="TEST VALID", oDlg
Local vAc01,vAc02
Local oAc01,oAc02

PREPARE FONT oFont NAME "MS Sans Serif" WIDTH 0 HEIGHT -14

 INIT DIALOG oDlg TITLE cTitulo Font oFont AT 0,0 SIZE 350,200 CLIPPER
NOEXIT NOEXITESC;
 STYLE DS_CENTER+WS_VISIBLE+WS_CAPTION

   vAc01 := "   "
   vAc02 := ""

   @ 010,030 say "Iniciais:" SIZE 60,15
   @ 010,050 get oAc01 VAR vAc01 picture "!!!"  SIZE 50,30 STYLE

   @ 010,090 say "Senha:" SIZE 65,15
   @ 010,110 get oAc02 VAR vAc02 PICTURE "!!!!!" SIZE 100,30 PASSWORD Valid
{||Hwg_MsgInfo("BUG Here !")}


ACTIVATE DIALOG oDlg
Return Nil

C:\fontes\teste>harbour -build
Harbour 3.2.0dev (r1306111826)
Copyright (c) 1999-2013, http://harbour-project.org/

Harbour Build Info
---------------------------
Version: Harbour 3.2.0dev (r1306111826)
Compiler: MinGW GNU C 4.7.2 (32-bit)
Platform: Windows 7 6.1.7601 Service Pack 1
PCode version: 0.3
ChangeLog last entry: 2013-06-11 20:26 UTC+0200 Przemyslaw Czerpak
(druzus/at/po
czta.onet.pl)
ChangeLog ID: bbdb15ce23480752ff235387e66d8cf0a7c2cb0c
Built on: Jun 11 2013 22:12:49
Build options: (Clipper 5.3b) (Clipper 5.x undoc)
---------------------------

Best regards,
Itamar M. Lins Jr.