[Harbour] 2008-11-30 23:49 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED])
2008-11-30 23:49 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED]) * harbour/contrib/gtwvg/wvggui.c * harbour/contrib/gtwvg/wvgdlg.prg * harbour/contrib/gtwvg/wvgphdlr.prg * harbour/contrib/gtwvg/wvgwnd.prg ! Cleanup - leftover trace calls. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/2008-11-30-23%3A49-UTC-0800-Pritpal-Bedi-%28pritpal%40vouchcac.com%29-tp20767409p20767409.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-30 23:05 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED])
Very compliment! for whath be use PRG/C level callback procedures? 2008/12/1 Pritpal Bedi <[EMAIL PROTECTED]> > > 2008-11-30 23:05 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED]) > * harbour/contrib/gtwvg/makefile > * harbour/contrib/gtwvg/common.mak >+ wvgparts.ch >+ wincallb.c >+ wincback.prg >+ wvglistb.prg >+ wvgpushb.prg >+ wvgstatb.prg >+ wvgstatc.prg >+ wvgtreev.prg > > * harbour/contrib/gtwvg/wvggui.c > * harbour/contrib/gtwvg/wvgsink.c > * harbour/contrib/gtwvg/wvgutils.c > * harbour/contrib/gtwvg/wvgwin.c > * harbour/contrib/gtwvg/hbgtwvg.ch > * harbour/contrib/gtwvg/wvgparts.ch > * harbour/contrib/gtwvg/wvtwin.ch > * harbour/contrib/gtwvg/wvgax.prg > * harbour/contrib/gtwvg/wvgcrt.prg > * harbour/contrib/gtwvg/wvgdlg.prg > * harbour/contrib/gtwvg/wvgmenub.prg > * harbour/contrib/gtwvg/wvgphdlr.prg > * harbour/contrib/gtwvg/wvgtoolb.prg > * harbour/contrib/gtwvg/wvgwnd.prg >! More synchronization, more events firings, etc. > > + harbour/contrib/gtwvg/wincback.prg > + harbour/contrib/gtwvg/wincallb.c >Now PRG/C level callback procedures/code blocks/methods >are made available by Andy Wos. A big thank you. > > :nWndProc := HB_AsCallBack( 'MYWNDPROC', Self ) > > METHOD MYWndProc( hWnd, nMessage, nwParam, nlParam ) > IF nMessage == WM_LBUTTONDOWN > Win_MessageBox( , 'Prg level callback procedure!, 'Info' ) > RETURN 0 > ENDIF > > RETURN 1 > > Before this mechanism was available with only C callbacks which > were of limiting nature. It has made our life so easy. > > + harbour/contrib/gtwvg/wvglistb.prg > + harbour/contrib/gtwvg/wvgcombo.prg > + harbour/contrib/gtwvg/wvgpushb.prg > + harbour/contrib/gtwvg/wvgstatb.prg > + harbour/contrib/gtwvg/wvgstatc.prg > + harbour/contrib/gtwvg/wvgtreev.prg >+ Added Xbase++ compatible new classes. > NOTE: Still a work-in-progress, subject to heavy changes. > Basic functionality is working and class skeletons are in place. > The partially functional classes added are: > WvgStatusBar() > WvgStatic() > WvgPushButton() > > * harbour/contrib/gtwvg/tests/demowvg.prg >+ Added functionality of new classes. > >; TOFIX: harbour/contrib/gtwvg/wvggui.c > Przemek, can you please look into this stripped down > version of gtwvg.c. It has memory leak in inkey() and > hb_gtInfo() functions. To test, just resize the window > and exit, bm, a big hb_out.log with above mem leak > entries. I am sure I just stripped some important loop > but am unable to locate where. > > Regards > Pritpal Bedi > -- > View this message in context: > http://www.nabble.com/2008-11-30-23%3A05-UTC-0800-Pritpal-Bedi-%28pritpal%40vouchcac.com%29-tp20767241p20767241.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano Albo Nazionale Informatici Professionisti 2620 Socio 2843 Associazione Informatici prof. Analisi e sviluppo software per Lan e Web Consulenza informatica - Formazione Delta Informatica S.r.l. http://www.deltain.it Via Torelli,31 - 28100 Novara - Tel: 0321/30281 ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] rddsql
Bruno Luciani wrote: Yes mindaugas I understand what do you say , I use DBF and RDDCDX but I like in future try other databases . In your experiencies how is the perfomance of rddsql and mysql or postgres when you load a database , in a browse ? respect DBF ? I hear that may be is not good in larger database, which is your experience ? thanks for your answers Bruno Hi, I'm using rddsql to access mysql databases on web server. This make nice integration of desktop app and web. I've never tried to compare speed to DBF, etc, but it's more a question of SQL speed itself. RDD does not add any calculation or speed overhead, it just stores data in memory. My web server database is not so large, so, I do not have experience. Best regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] PRG Function as a Window's Callback Procedure
Hi!
Pritpal Bedi wrote:
>
> Hello
>
> I am looking for a way ( I am sure it exists ) to do something
> like this:
>
> HB_FUNC( WIN_SETWNDPROC )
> {
>HWND hWnd = ( HWND ) ( HB_PTRDIFF ) hb_parnint( 1 );
>WNDPROC wndProc = ( WNDPROC ) ( HB_PTRDIFF ) hb_parnint( 2 );
>WNDPROC oldProc;
>
>oldProc = ( WNDPROC ) SetWindowLong( hWnd, GWL_WNDPROC,( long ) wndProc
> ) ;
>
>hb_retnint( ( HB_PTRDIFF ) oldProc );
> }
>
> and fron prg code :
>
> METHOD MyMethod()
>Win_SetWndProc( ::hWnd, @WndProc() ) // or LIKE
>//
>Return Self
>
> Function/Method WndProc( hWnd, nMessage, nwParam, nlParam )
>// take action
>Return 0
>
Mayby You try like in HMG (Harbour MiniGUI) doing.
PROCEDURE main
LOCAL hWnd
hWnd := GetWindowHandle("NameWindow")
SetWindowProc(hWnd,.T.)
...
SetWindowProc(hWnd,.F.)
...
RETURN
**
//window callback function in PRG
FUNCTION PrgWindowProc( hWnd, nMsg, wParam, ,lParam )
#define WM_MOUSEMOVE0x0200
#define WM_LBUTTONDOWN 0x0201
#define WM_LBUTTONUP0x0202
DO CASE
CASE nMsg == WM_MOUSEMOVE
...
RETURN 1
CASE nMsg == WM_LBUTTONDOWN
...
CASE nMsg == WM_LBUTTONUP
...
ENDCASE
RETURN 0
***
#pragma BEGINDUMP
#include
#include
#include
#include
#include "hbapi.h"
#include "hbvm.h"
LRESULT CALLBACK MyWindowProc (HWND hWin, UINT Msg, WPARAM wParam, LPARAM
lParam)
{
static PHB_SYMB pSymbol = NULL;
long int r;
WNDPROC OldWndProc;
OldWndProc = (WNDPROC)GetProp( hWin, "oldwindowproc" );
switch( Msg )
{
case WM_DESTROY:
SetWindowLong( hWin, GWL_WNDPROC, (DWORD)OldWndProc
);
RemoveProp( hWin, "oldwindowproc" );
break;
case WM_LBUTTONDOWN:
case WM_LBUTTONUP:
case WM_MOUSEMOVE:
{
if ( ! pSymbol)
{
pSymbol = hb_dynsymSymbol( hb_dynsymGet(
"PRGWINDOWPROC" ));
}
if ( pSymbol )
{
hb_vmPushSymbol( pSymbol );
hb_vmPushNil();
hb_vmPushLong( ( LONG ) hWin );
hb_vmPushLong( Msg );
hb_vmPushLong( wParam );
hb_vmPushLong( lParam );
hb_vmDo( 4 );
}
r = hb_parnl( -1 );
if ( r != 0 )
{
return r ;
}
else
{
return( CallWindowProc( OldWndProc, hWin,
Msg, wParam, lParam ) );
}
}
}
return( CallWindowProc( OldWndProc, hWin, Msg, wParam, lParam ) );
}
//
HB_FUNC ( SETWINDOWPROC ) // SeWindowProc(hWindow,lSet)
{
WNDPROC OldWndProc;
HWND hWin = (HWND) hb_parnl(1) ;
if( hb_parl(2) )
{
SetProp( hWin, "oldwindowproc", (HWND) GetWindowLong( hWin,
GWL_WNDPROC ) ) ;
SetWindowLong( hWin, GWL_WNDPROC, (LONG)(WNDPROC)MyWindowProc ) ;
}
else
{
OldWndProc = (WNDPROC)GetProp( hWin, "oldwindowproc" );
SetWindowLong( hWin, GWL_WNDPROC, (DWORD)OldWndProc );
RemoveProp( hWin, "oldwindowproc" );
}
}
#pragma ENDDUMP
--
View this message in context:
http://www.nabble.com/PRG-Function-as-a-Window%27s-Callback-Procedure-tp20758851p20774496.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Fri, 28 Nov 2008, Przemyslaw Czerpak wrote: Hi Mindaugas, > In this weekend or at the beginning of next one I'll try to create some > basic core version. I would like to ask you about permission to move your hb_compI18n*() functions from hbmain.c to separate file with license having Harbour exception. Can I do that? best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi,
In Lithuanian language plural forms does not always solves the problem,
because we need more that 2 word ending. AFAIK, the same problem is for
Polish translations. I guess we can live without plurals.
This is resolved in gettext. At least for European languages.
Usually it's possible to define some limited number of basic
rules which depends on given number. F.e. in Polish there are
3 forms: for 1, for numbers ending with 2,3,4 except 11,12,...,19
and for rest.
1 dom
2 domy, 3 domy, 4 domy, 22 domy, 34 domy
5 domów, 6 domów, 11 domów, 13 domów, 31 domów, 45 domów
In Lithuanian you have also 3 forms:
1. for numbers ending with 10, 11, 12, 13, ..., 19
2. for numbers ending with 1
3. for rest
I remembered the problem. I wanted to create app with Lithuanian source
code language, but ngettext() is adopted for english source code.
Do you mean just an overloading of i18n C function by other module, or some
more complex possibility to have alternative gettext?
I'm thinking about simple table with function address which can be
overloaded using some public function so it will be possible to
replace our default functions by user ones.
This can put some restrictions on Harbour's i18n implementation. We will
have to be more GNU gettext compatible and could be more difficult to
gave a different meaning of context or domains, etc. But if you'll find
a solution for both Harbour's i18n and original getetxt, it would be great.
I know about it and I agree that it's not strictly necessary but
I do not know if people who do not use latin base languages will
share this opinion.
If translation tables are not used
cI := i18n_gettext("some text")
is equivalent to
cI := "some text"
So, I don't think we must to input strings. Or... it should be a more
general codepage solution for all strings of Harbour source.
In our own implementation we can define different meaning for domain
then the one which exists in gettext where inside each domain you
have translations for different languages.
In gettext each domain has translations for different libraries (not
languages). (I guess you meant this, but it's just a typing error)
When someone decide to
use our own i18n implementation then usually need it only for his own
application and does not need domains defined like for gettext.
We can also use domains for context translations.
It's our choice.
It would be great, if we can do this way. We support domains and it's
programmers choice use it for libraries or contexts. The only problem to
be solved is how to store domains. In original implementation domain
translations are in different files, but translation for all contexts
are in the same file. We will need to implement one more level in
translation tables. Something like:
{"LANGUAGE"=>"PL_PL", "CPID"=>"PLISO",
"TABLE"=>{""/*no domain*/=>{...}, "DOMAIN1"=>{...}, ...}}
And we can use domain as context signature for alternative translations.
In such case when domain is given we will look for translation in given
domain and if it's not found then in main domain.
To resolve context problem we can also define some dummy pattern which
will be eliminated by our own hb_strFormat() function and use it to create
unique strings, f.e.:
"[EMAIL PROTECTED]"
"[EMAIL PROTECTED]"
%@ will be replaced by empty string.
Yes. I'm currently using a similar solution, but it's a little hackish
and that's why I do not like it a lot.
Best regards,
Mindaugas
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] itemGetNL & dates
Hi, hb_itemGetNL() is implemented to return Julian date value instead of 0. Why? (IMHO, date is not numeric and hb_itemGetDL() should be used) Best regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi, Przemyslaw Czerpak wrote: I would like to ask you about permission to move your hb_compI18n*() functions from hbmain.c to separate file with license having Harbour exception. Can I do that? YES, of cause. Best regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] itemGetNL & dates
On Mon, 01 Dec 2008, Mindaugas Kavaliauskas wrote: Hi Mindaugas, > hb_itemGetNL() is implemented to return Julian date value instead of 0. > Why? (IMHO, date is not numeric and hb_itemGetDL() should be used) I do not know. Probably for some historical reasons. In Clipper the result of _itemGetNL( pDateItm ) is undefined and tests confirm it. But _parnl( iParam ) seems to return Julian date when iParam is date item. Probably some of conversions we have in hb_itemGet*() functions are used to emulate unprotected access to ITEM internals in Clipper in _itemGet*() functions. But I cannot say which ones and which were added by Harbour developers as some type of Harbour extensions. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Mon, 01 Dec 2008, Mindaugas Kavaliauskas wrote: Hi, > Przemyslaw Czerpak wrote: >> I would like to ask you about permission to move your hb_compI18n*() >> functions from hbmain.c to separate file with license having Harbour >> exception. Can I do that? > YES, of cause. Thank you. I'll also change it a little bit to store with lines real file name with path instead of main module name so it will work correctly for #included code and with gettext translation tools which can extract source code context to help in translations. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Mon, 01 Dec 2008, Mindaugas Kavaliauskas wrote:
Hi,
>> In Lithuanian you have also 3 forms:
>>1. for numbers ending with 10, 11, 12, 13, ..., 19
>>2. for numbers ending with 1
>>3. for rest
> I remembered the problem. I wanted to create app with Lithuanian source
> code language, but ngettext() is adopted for english source code.
Yes, it is.
I also think about it. The same problem I have when I want to use
Polish as base language. I'm thinking about adding our own extension
for it, sth like:
hb_gettext( { [, ] } [, ], )
or:
hb_ngettext( , { [, ] } [, ] )
So it will be possible to use also non English languages as base.
In such case programmer will have to set plural index rule at application
startup. The default one will be: iif( n == 1, 1, 2 )
If there is translation with corresponding plural index but at least one
exists then we can use the 1-st one. In such case it will not be necessary
to repeat the same translations when the translated one has only one form
in given language.
In .pot file we may store base strings as:
msgid "single form"
msgid_plural "plural form 1"
msgid_plural2 "plural form 2"
so as long as someone will use only two forms it will be gettext compatible.
msgid will be still main hash index and msgid_plural* will be used only as
optional results when nCount is given and and index created from nCount has
corresponding msgid_plural* entry.
What do you think about it?
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] itemGetNL & dates
hb_itemGetNL() is implemented to return Julian date value instead of 0.
Why? (IMHO, date is not numeric and hb_itemGetDL() should be used)
I do not know. Probably for some historical reasons. In Clipper the
result of _itemGetNL( pDateItm ) is undefined and tests confirm it.
But _parnl( iParam ) seems to return Julian date when iParam is date
item. Probably some of conversions we have in hb_itemGet*() functions
are used to emulate unprotected access to ITEM internals in Clipper
in _itemGet*() functions. But I cannot say which ones and which were
added by Harbour developers as some type of Harbour extensions.
Hi,
I've check Clipper. It seems _itemGetNL() always return value and does
not checks item's type at all. It returns object manager handle for
strings, arrays and codeblocks, ds segment offsets (in low word of
return value) for references and also half (4 bytes) of 8 byte double
value. In our language _itemGetNL() is:
LONG hb_itemGetNL( PHB_ITEM pItem )
{
return ( LONG ) pItem->item.asLong.value;
}
_parnl() returns numeric values for long, date and double types and 0
otherwise.
My problem was that I've used code:
l = hb_itemGetNL( pItem );
instead of
if ( HB_IS_NUMERIC( pItem ) )
{
l = hb_itemGetNL( pItem );
}
else
{
l = 0;
}
hoping that return value is 0, if item type is not numeric. But it is
not true for the dates.
I can live with it, but I would support removing Julian date value
return from hb_itemGetNL() and hb_parnl() to make Harbour implementation
more correct and error resistant. Clipper was using those functions for
dates because there were no _itemGetDL() and _pardl() in Clipper. We
have special function for the dates, so, there is no need to emulate
side effects of Clipper.
It would be nice to hear other opinions.
Best regards,
Mindaugas
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Przemyslaw Czerpak wrote:
Yes, it is.
I also think about it. The same problem I have when I want to use
Polish as base language. I'm thinking about adding our own extension
for it, sth like:
hb_gettext( { [, ] } [, ], )
or:
hb_ngettext( , { [, ] } [, ] )
So it will be possible to use also non English languages as base.
In such case programmer will have to set plural index rule at application
startup. The default one will be: iif( n == 1, 1, 2 )
If there is translation with corresponding plural index but at least one
exists then we can use the 1-st one. In such case it will not be necessary
to repeat the same translations when the translated one has only one form
in given language.
In .pot file we may store base strings as:
msgid "single form"
msgid_plural "plural form 1"
msgid_plural2 "plural form 2"
so as long as someone will use only two forms it will be gettext compatible.
msgid will be still main hash index and msgid_plural* will be used only as
optional results when nCount is given and and index created from nCount has
corresponding msgid_plural* entry.
What do you think about it?
Hi,
that would be great! GNU gettext developers should hear you.
Regards,
Mindaugas
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
