[Harbour] Closing relation
Hi, is there any way in Harbour/Clipper to close a single relation of workarea? Best regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OSX (and Linux) and dyn libs
Szakáts Viktor wrote: > > Windows, OS/2 and DOS doesn't need an (extended) installer, > and this makes them very flexible to use. IMO, if there is > any chance to replicate that (and I believe there is), > we shouldn't cut the way to allow this on as much platforms Viktor, in OS/2 there is an envvar, LIBPATH=, which always contains '.' and is used by OS/2 to find needed DLLs; so every program looks at the dirctory it was started from when looking for .DLLs. I don't think this is available on MacOSX. > as possible. In OS X, installation is rather the exception > than the rule, which is just one more reason to allow support > for it (especially if it doesn't hurt anyone). > I agree with you here, and with something you wrote later, MacOSX is not linux, so it is wrong to see it just like a unix dialect with some fancy window manager. That said, what about having MacOSX specific commands instead of changing the ones that work on most the other *nixes? Maurilio. > Brgds, > Viktor > > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] MT and hb_gtInfo() - Appln Locks
On Thu, 20 Nov 2008, Pritpal Bedi wrote:
Hi Pritpal,
> Function Main()
>hb_threadStart( {|| First() } )
>hb_threadStart( {|| Second() } )
>do while .t.
>nKey := inkey( 0.2 )
>if nKey == 27
> exit
>endif
>enddo
>Return nil
> Function First()
>hb_gtInfo( HB_GTI_WINTITLE, 'My First Function' ) // Appln Hangs
>Return nil
> Function Second()
>@ 10,20 SAY 'My Second Function' COLOR 'W+/R'// This works ok
>Return nil
> hb_gtInfo() may be looking GT in another context.
It has nothing to GT context which works perfectly (as far as I know).
Few days ago I sent to this list message which explains why such effects
can apear. Please read it again. Now short reduction.
Do you remembert the problem with locking GT you had?
You were arbitrary unlocking it and I tried to tell you
that the problem is not directly related to GT locking
but it's result of Windows API behavior and GT locking
only exploits it. In Windows _ONLY_ thread which created
windows can process windows messages. It means that if
other thread send blocking message then it will be locked
until the thread which created the window will not process
it. I suggested you to locate all such functions and use
their alternative version which will not lock GT or if such
alternative version does not exist to unlock GT before
calling blocking function or you will have deadlock.
Arbitrary unlocking GT inside hb_gtInfoEx() you made and
accessing GT structure with any protection is not a solution
because it may cause that two threads will operate on the
same structure without any protection what may cause its
corruption and the deadlock problem still exists and will
be exploited when user code will begin to use locks.
Code above is example of such deadlock situation.
Two function: GetWindowText() and SetWindowText() are
blocking functions. If you want to allow setting window
title from other threads then the one which created
the window (just like in you example) then you should
change GTWV[TG] code. If you want to only resolve problem
with deadlock which can appear on internal MS-windows mutext
used to protect window and pGT mutex used to protect our
pGT structure then it's enough to unlock pGT before calling
SetWindowText()/GetWindowText() and then resotre the locks.
F.e. this modification resolves the problem in above exmpale:
static void hb_gt_wvt_SetWindowTitle( PHB_GT pGT, HWND hWnd, const char * title
)
{
LPTSTR text = HB_TCHAR_CONVTO( title );
/* SetWindowText() will block this thread until the thread which
* created window will not process window messages. To allow processing
* window message for thread which is window owner we have to unlock
* the GT so it can access it. Otherwise we will have deadlock.
*/
HB_GTSELF_UNLOCK( pGT );
SetWindowText( hWnd, text );
HB_GTSELF_LOCK( pGT );
HB_TCHAR_FREE( text );
}
static BOOL hb_gt_wvt_GetWindowTitle( PHB_GT pGT, HWND hWnd, char ** title )
{
TCHAR buffer[ WVT_MAX_TITLE_SIZE ];
int iResult;
HB_GTSELF_UNLOCK( pGT );
/* GetWindowText() will block this thread until the thread which
* created window will not process window messages.
*/
iResult = GetWindowText( hWnd, buffer, WVT_MAX_TITLE_SIZE );
HB_GTSELF_LOCK( pGT );
if( iResult > 0 )
{
*title = ( char * ) hb_xgrab( iResult + 1 );
HB_TCHAR_GETFROM( *title, buffer, iResult );
( *title )[ iResult ] = '\0';
return TRUE;
}
*title = NULL;
return FALSE;
}
Add it to GTWVT and update hb_gt_wvt_SetWindowTitle() and
hb_gt_wvt_GetWindowTitle() calls to add pGT as 1-st parameter.
Anyhow it's not very good solution because the problem can return
when user code will use some locks. F.e. thread can lock some user
mutex which will stop the thread which created the window. When
this thread calls SetWindowText() or GetWindowText() then we
have exactly the same deadlock.
So you should create alternate solution which will not lock the
thread or you can keep above modification but you have to document
that HB_GTI_WINTITLE is locking action in GTWV[TG] and user should
resolve the potential deadlock problem in his code himself. F.e.
he should unlock your own mutexes before calling it and then lock
them again.
I do not like it so I prefer unlocking solution but the second
one is also acceptable. It's only important to well document
such actions so user will know about it.
In this case (setting window title) you can resolve the problem
quite easy. It's enough to keep window tile in pWVT variable
(it will eliminate GetWindowText() calls) and call SetWindowText()
only by thread which created the window. You can store thread ID
(HB_THREAD_SELF()) for thread which create window inside pWVT
structure so you can check it.
There is also yet another solution. You can create non HVM thread
which will be used to create all windows and process their message
queues. It will not make any other jobs so it will be always available
a
Re: [Harbour] MT and hb_gtInfo() - Appln Locks
Przemek Przemyslaw Czerpak-2 wrote: > > There is also yet another solution. You can create non HVM thread > which will be used to create all windows and process their message > queues. It will not make any other jobs so it will be always available > and other threads which may call locking windows API function will > not have to worry about deadlock because all locks used by window > owner thread will be known. This also resolve the problem of > automatic window refreshing. > All other solutions are too much and all GTs must have to be modified to respect it. Non HVM thread creating windows and managing its message loop appears to be the right solution. It will also open some interesting possibilities. Can you guide me how this can be done? I will do all efforts to materialize it. I do not use hb_gtInfoEx() as it also has sweare implications. About to be removed from the sources. You are right that this hack is dangerous. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/MT-and-hb_gtInfo%28%29---Appln-Locks-tp20613862p20622543.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
[Harbour] hbapi.h and DWORD values
Hi all, Is there a way to return a DWORD value using HBAPI.H or does this conversion (ie. from LONG to DWORD) need to be done at the PRG level? Regards, Randy. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbapi.h and DWORD values
Hi, Is there a way to return a DWORD value using HBAPI.H or does this conversion (ie. from LONG to DWORD) need to be done at the PRG level? Try hb_retnint( (HB_LONG) dword ); Regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Closing relation
On Fri, 21 Nov 2008, Mindaugas Kavaliauskas wrote: Hi Mindaugas, > is there any way in Harbour/Clipper to close a single relation of workarea? No. There are no RDD methods which allows to implement it. You can hardcode it without RDD API but it's rather bad idea. You can also collect information about active relations, clear all and then restore them except the one you want to remove but it will work only if all relation expressions can be recompiled using their string expressions. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
