subject:"\[Harbour\] Question about hb_gt_win


Viktor,


It also doesn't work on Vista/Win7/2008.


Maybe is about CTRL_LOGOFF_EVENT, CTRL_SHUTDOWN_EVENT that is received only by 
services.
But if so is a issue of Vista and Win7/2008, not ours, because the official 
documentation nothing says about this, AFAIK.
And no excuse for not correcting the current Harbour behavior, IMHO.
Also in .NET (please see example Visual C++ and Platforms) .-

http://msdn.microsoft.com/en-us/library/system.gc.keepalive%28VS.100%29.aspx


I tested it on XP x64, there there is a window
asking for 'Cancel' and 'End Now', so even here
this method cannot prevent the app to be closed
by user. In any case it's not a SETCANCEL() thing,


Just as DOS Clipper's programs.


but maybe rather it could be the standard GTWIN
behavior (without any extra setting). For sure
it's not a HB_GTI_CLOSABLE setting either. Or,
we just leave it as is.


IMHO are two different targets, things, HB_GTI_CLOSABLE / SETCANCEL.
HB_GTI_CLOSABLE aims to modify the user interface (if possible).
SETCANCEL aims to avoid interruption of the code execution by the user (if 
possible).
BTW in te case of GTWVT, I don't think that changing the status of SETCANCEL in response to WM_CLOSE meet the objective of 
SETCANCEL.


--
Xavi

El 04/03/2010 20:38, Viktor Szakáts escribió:

It also doesn't work on Vista/Win7/2008.

Did _you_ read the comments in your quoted (now
for the 6th times) article?

I tested it on XP x64, there there is a window
asking for 'Cancel' and 'End Now', so even here
this method cannot prevent the app to be closed
by user. In any case it's not a SETCANCEL() thing,
but maybe rather it could be the standard GTWIN
behavior (without any extra setting). For sure
it's not a HB_GTI_CLOSABLE setting either. Or,
we just leave it as is.

Brgds,
Viktor

On 2010 Mar 4, at 20:21, Xavi wrote:


Sorry I meant SetCancel(.F.)

http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx

"
An application-defined function used with the SetConsoleCtrlHandler function. A 
console process uses this function to handle control signals received by the 
process. When the signal is received, the system creates a new thread in the 
process to execute the function.
"

PROCEDURE Main()

   SetCancel(.F.)
   ? "Click [X] Not close windows"
   Wait
   RETURN

Now it's happening that you are introduced ch = HB_BREAK_FLAG in Inkey Poll, 
keyboard buffer.
Wait ends and the main process is finished so the new thread to execute the 
function is killed before it can complete their work.

--
Xavi

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

It also doesn't work on Vista/Win7/2008.

Did _you_ read the comments in your quoted (now 
for the 6th times) article?

I tested it on XP x64, there there is a window 
asking for 'Cancel' and 'End Now', so even here 
this method cannot prevent the app to be closed 
by user. In any case it's not a SETCANCEL() thing, 
but maybe rather it could be the standard GTWIN 
behavior (without any extra setting). For sure 
it's not a HB_GTI_CLOSABLE setting either. Or, 
we just leave it as is.

Brgds,
Viktor

On 2010 Mar 4, at 20:21, Xavi wrote:

> Sorry I meant SetCancel(.F.)
> 
> http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx
> 
> "
> An application-defined function used with the SetConsoleCtrlHandler function. 
> A console process uses this function to handle control signals received by 
> the process. When the signal is received, the system creates a new thread in 
> the process to execute the function.
> "
> 
> PROCEDURE Main()
> 
>   SetCancel(.F.)
>   ? "Click [X] Not close windows"
>   Wait
>   RETURN
> 
> Now it's happening that you are introduced ch = HB_BREAK_FLAG in Inkey Poll, 
> keyboard buffer.
> Wait ends and the main process is finished so the new thread to execute the 
> function is killed before it can complete their work.
> 
> -- 
> Xavi
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage


Sorry I meant SetCancel(.F.)

http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx

"
An application-defined function used with the SetConsoleCtrlHandler function. A console process uses this function to handle 
control signals received by the process. When the signal is received, the system creates a new thread in the process to execute 
the function.

"

PROCEDURE Main()

   SetCancel(.F.)
   ? "Click [X] Not close windows"
   Wait
   RETURN

Now it's happening that you are introduced ch = HB_BREAK_FLAG in Inkey Poll, 
keyboard buffer.
Wait ends and the main process is finished so the new thread to execute the 
function is killed before it can complete their work.

--
Xavi
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

It doesn't work on Vista and Win7/2008.

Brgds,
Viktor

On 2010 Mar 4, at 20:16, Xavi wrote:

> [ I don't know because I've to answer this. Maybe the last time. :( ]
> 
> http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx
> 
> "
> An application-defined function used with the SetConsoleCtrlHandler function. 
> A console process uses this function to handle control signals received by 
> the process. When the signal is received, the system creates a new thread in 
> the process to execute the function.
> "
> 
> PROCEDURE Main()
> 
>   SetCancel(.T.)
>   ? "Click [X] Not close windows"
>   Wait
>   RETURN
> 
> Now it's happening that you are introduced ch = HB_BREAK_FLAG in Inkey Poll, 
> keyboard buffer.
> Wait ends and the main process is finished so the new thread to execute the 
> function is killed before it can complete their work.
> 
> -- 
> Xavi
> 
> El 04/03/2010 18:47, Viktor Szakáts escribió:
>>> http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx
>>> 
>>> "
>>> Return TRUE. In this case, no other handler functions are called, and
>>> the system displays a pop-up dialog box that asks the user whether to
>>> terminate the process. The system also displays this dialog box if the
>>> process does not respond within a certain time-out period (5 seconds
>>> for CTRL_CLOSE_EVENT, and 20 seconds for CTRL_LOGOFF_EVENT or
>>> CTRL_SHUTDOWN_EVENT).
>>> "
>>> 
>>> What you don't understand about this part of the official documentation?
>> 
>> Read this:
>> 
>> Different behavior for Vista and later   Master Programmer
>>  | Edit | Show
>> History
>> 
>> It seems like for Vista and later, the system terminates the process
>> soon after it calls this routine.
>> 
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage


[ I don't know because I've to answer this. Maybe the last time. :( ]

http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx

"
An application-defined function used with the SetConsoleCtrlHandler function. A console process uses this function to handle 
control signals received by the process. When the signal is received, the system creates a new thread in the process to execute 
the function.

"

PROCEDURE Main()

   SetCancel(.T.)
   ? "Click [X] Not close windows"
   Wait
   RETURN

Now it's happening that you are introduced ch = HB_BREAK_FLAG in Inkey Poll, 
keyboard buffer.
Wait ends and the main process is finished so the new thread to execute the 
function is killed before it can complete their work.

--
Xavi

El 04/03/2010 18:47, Viktor Szakáts escribió:

http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx

"
Return TRUE. In this case, no other handler functions are called, and
the system displays a pop-up dialog box that asks the user whether to
terminate the process. The system also displays this dialog box if the
process does not respond within a certain time-out period (5 seconds
for CTRL_CLOSE_EVENT, and 20 seconds for CTRL_LOGOFF_EVENT or
CTRL_SHUTDOWN_EVENT).
"

What you don't understand about this part of the official documentation?


Read this:

Different behavior for Vista and later  Master Programmer
 | Edit | Show
History

It seems like for Vista and later, the system terminates the process
soon after it calls this routine.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

> http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx
> 
> "
> Return TRUE. In this case, no other handler functions are called, and the 
> system displays a pop-up dialog box that asks the user whether to terminate 
> the process. The system also displays this dialog box if the process does not 
> respond within a certain time-out period (5 seconds for CTRL_CLOSE_EVENT, and 
> 20 seconds for CTRL_LOGOFF_EVENT or CTRL_SHUTDOWN_EVENT).
> "
> 
> What you don't understand about this part of the official documentation?

Read this:

Different behavior for Vista and later  Master Programmer   |   Edit   
|   Show History
It seems like for Vista and later, the system terminates the process soon after 
it calls this routine.___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

>> Can you describe what is exactly this "expected" result?
> 
> http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx
> 
> "
> Return TRUE. In this case, no other handler functions are called, and the 
> system displays a pop-up dialog box that asks the user whether to terminate 
> the process. The system also displays this dialog box if the process does not 
> respond within a certain time-out period (5 seconds for CTRL_CLOSE_EVENT, and 
> 20 seconds for CTRL_LOGOFF_EVENT or CTRL_SHUTDOWN_EVENT).
> "
> 
> What you don't understand about this part of the official documentation?
> Need you a picture of the pop-up dialog box which _allows to continue the 
> process_?

With a stamp, yes. Nevermind.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

Can you describe what is exactly this "expected" result?

http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx

"
Return TRUE. In this case, no other handler functions are called, and the system displays a pop-up dialog box that asks the user
whether to terminate the process. The system also displays this dialog box if the process does not respond within a certain
time-out period (5 seconds for CTRL_CLOSE_EVENT, and 20 seconds for CTRL_LOGOFF_EVENT or CTRL_SHUTDOWN_EVENT).

What you don't understand about this part of the official documentation?
Need you a picture of the pop-up dialog box which _allows to continue the
process_?

--
Xavi

El 04/03/2010 16:23, Viktor Szakáts escribió:

I was referring to your patch. Did you
try it with a test application with both
SETCANCEL(.T.) and SETCANCEL(.F.) ?

IMHO this difference can be assumed because the code must be fixed in MT mode.
[
#if ! defined( HB_MT_VM )&& 0
if( hb_setGetCancel() )
s_bBreak = HB_TRUE;
#endif
]

I tested in ST mode, and s_bBreak has no effect
on the application termination, meaning that it
will be _always_ closed. (regardless of SETCANCEL()
or whatever else control we use here)

... !!! ??? Sorry... What's happening? :)

Please tell me more.
Have these tested in a real Windows machine?

It's a VMWare Fusion 3.0.2 VM, but that's irrelevant here.

What version of Windows OS?

Tested on Win7 x64 using win/mingw (x86) Harbour trunk.

What version of kernel32.dll?
Does the same thing the Clipper's program on your machine?

What do you mean? I'm not aware of any method
you can disable NTVDM "close" for Clipper
programs, even less so using SETCANCEL().

But NTVDM is no more on x64 Windows editions.

Obviously I have the expected result in XP SP3.

Can you describe what is exactly this "expected" result?

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

>> I was referring to your patch. Did you
>> try it with a test application with both
>> SETCANCEL(.T.) and SETCANCEL(.F.) ?
>> 
>>> IMHO this difference can be assumed because the code must be fixed in MT 
>>> mode.
>>> [
>>> #if ! defined( HB_MT_VM )&&  0
>>> if( hb_setGetCancel() )
>>>s_bBreak = HB_TRUE;
>>> #endif
>>> ]
>> 
>> I tested in ST mode, and s_bBreak has no effect
>> on the application termination, meaning that it
>> will be _always_ closed. (regardless of SETCANCEL()
>> or whatever else control we use here)
> 
> ... !!! ??? Sorry... What's happening? :)
> 
> Please tell me more.
> Have these tested in a real Windows machine?

It's a VMWare Fusion 3.0.2 VM, but that's irrelevant here.

> What version of Windows OS?

Tested on Win7 x64 using win/mingw (x86) Harbour trunk.

> What version of kernel32.dll?
> Does the same thing the Clipper's program on your machine?

What do you mean? I'm not aware of any method 
you can disable NTVDM "close" for Clipper 
programs, even less so using SETCANCEL().

But NTVDM is no more on x64 Windows editions.

> Obviously I have the expected result in XP SP3.

Can you describe what is exactly this "expected" result?

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage


Did you test this code?


Yes, if you're referring to that SetCancel( .T. ) Clipper's program under NTVDM 
differs.


I was referring to your patch. Did you
try it with a test application with both
SETCANCEL(.T.) and SETCANCEL(.F.) ?


IMHO this difference can be assumed because the code must be fixed in MT mode.
[
#if ! defined( HB_MT_VM )&&  0
 if( hb_setGetCancel() )
s_bBreak = HB_TRUE;
#endif
]


I tested in ST mode, and s_bBreak has no effect
on the application termination, meaning that it
will be _always_ closed. (regardless of SETCANCEL()
or whatever else control we use here)


... !!! ??? Sorry... What's happening? :)

Please tell me more.
Have these tested in a real Windows machine?
What version of Windows OS?
What version of kernel32.dll?
Does the same thing the Clipper's program on your machine?

Obviously I have the expected result in XP SP3.
kernel32.dll version 5.1.2600.5512 DLL de cliente API BASE de Windows NT

http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx

"The system also displays this dialog box if the process does not respond within a certain time-out period (5 seconds for 
CTRL_CLOSE_EVENT, and 20 seconds for CTRL_LOGOFF_EVENT or CTRL_SHUTDOWN_EVENT)."


--
Xavi

El 04/03/2010 14:52, Viktor Szakáts escribió:

Did you test this code?


Yes, if you're referring to that SetCancel( .T. ) Clipper's program under NTVDM 
differs.


I was referring to your patch. Did you
try it with a test application with both
SETCANCEL(.T.) and SETCANCEL(.F.) ?


IMHO this difference can be assumed because the code must be fixed in MT mode.
[
#if ! defined( HB_MT_VM )&&  0
 if( hb_setGetCancel() )
s_bBreak = HB_TRUE;
#endif
]


I tested in ST mode, and s_bBreak has no effect
on the application termination, meaning that it
will be _always_ closed. (regardless of SETCANCEL()
or whatever else control we use here)


But I do a new question.
How can it be fixed something that does not exist?


I don't know what you mean, sorry.

Nothing needs to be fixed, since nothing is
currently wrong or broken. AFAICS what you want
is to attach GT specific window-close behavior
to SETCANCEL(). Current behavior is not a bug,
but by design. I can't see why you want to limit
current possibilities and make it impossible to
have a working Ctrl+C key plus a regular closable
window. Not to mention that you can't attach
window-close behavior is several GTs, GTWIN
is just one of those, we also have GTOS2, GTSTD,
GTPCA, GTDOS, GTTRM, GTCRS, GTSLN. Please notice
that a "window" per se is not in reach with
all/most non-GUI GTs.

Brgds,
Viktor


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

>> Did you test this code?
> 
> Yes, if you're referring to that SetCancel( .T. ) Clipper's program under 
> NTVDM differs.

I was referring to your patch. Did you 
try it with a test application with both 
SETCANCEL(.T.) and SETCANCEL(.F.) ?

> IMHO this difference can be assumed because the code must be fixed in MT mode.
> [
> #if ! defined( HB_MT_VM ) && 0
> if( hb_setGetCancel() )
>s_bBreak = HB_TRUE;
> #endif
> ]

I tested in ST mode, and s_bBreak has no effect 
on the application termination, meaning that it 
will be _always_ closed. (regardless of SETCANCEL() 
or whatever else control we use here)

> But I do a new question.
> How can it be fixed something that does not exist?

I don't know what you mean, sorry.

Nothing needs to be fixed, since nothing is 
currently wrong or broken. AFAICS what you want 
is to attach GT specific window-close behavior 
to SETCANCEL(). Current behavior is not a bug, 
but by design. I can't see why you want to limit 
current possibilities and make it impossible to 
have a working Ctrl+C key plus a regular closable 
window. Not to mention that you can't attach 
window-close behavior is several GTs, GTWIN 
is just one of those, we also have GTOS2, GTSTD, 
GTPCA, GTDOS, GTTRM, GTCRS, GTSLN. Please notice 
that a "window" per se is not in reach with 
all/most non-GUI GTs.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage


Hi,


Did you test this code?


Yes, if you're referring to that SetCancel( .T. ) Clipper's program under NTVDM 
differs.
IMHO this difference can be assumed because the code must be fixed in MT mode.
[
#if ! defined( HB_MT_VM ) && 0
 if( hb_setGetCancel() )
s_bBreak = HB_TRUE;
#endif
]

But I do a new question.
How can it be fixed something that does not exist?

[ And is not valid the quick answer "does not exist, no problem" because by 
this logic Harbour would be perfect if not exist. :) ]

Best regards,
--
Xavi

El 04/03/2010 8:31, Viktor Szakáts escribió:

Hi Xavi,


Yes, you're right.
I have another patch to fix this, IMHO a issue, but I don't have right to 
commit it, there are two differents points of view and few opinions. Please 
note that GTWIN behavior is the same as a Clipper program under NTVDM.

--- .patch
Index: gtwin.c
===
--- gtwin.c (revision 14052)
+++ gtwin.c (working copy)
@@ -563,7 +563,9 @@

   case CTRL_CLOSE_EVENT:
   case CTRL_BREAK_EVENT:
- s_bBreak = HB_TRUE;
+ /* Avoid irregular shutdown if SetCancel( .F. ) [jarabal] */
+ if( hb_setGetCancel() )
+s_bBreak = HB_TRUE;
  bHandled = TRUE;
  break;


Did you test this code?

Brgds,
Viktor


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

Hi Xavi,

> Yes, you're right.
> I have another patch to fix this, IMHO a issue, but I don't have right to 
> commit it, there are two differents points of view and few opinions. Please 
> note that GTWIN behavior is the same as a Clipper program under NTVDM.
> 
> --- .patch
> Index: gtwin.c
> ===
> --- gtwin.c   (revision 14052)
> +++ gtwin.c   (working copy)
> @@ -563,7 +563,9 @@
> 
>   case CTRL_CLOSE_EVENT:
>   case CTRL_BREAK_EVENT:
> - s_bBreak = HB_TRUE;
> + /* Avoid irregular shutdown if SetCancel( .F. ) [jarabal] */
> + if( hb_setGetCancel() )
> +s_bBreak = HB_TRUE;
>  bHandled = TRUE;
>  break;

Did you test this code?

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

2010-03-03 Thread Xavi


Hi,


I'm trying to write a simple Hello World app that does something like a
WAIT command and maybe calls a function if I click the X button for a
GTWIN app.


Yes, you're right.
I have another patch to fix this, IMHO a issue, but I don't have right to commit it, there are two differents points of view and 
few opinions. Please note that GTWIN behavior is the same as a Clipper program under NTVDM.


===

* harbour/src/rtl/gtwin/gtwin.c
 ! Fixing CTRL_BREAK_EVENT, and CTRL_CLOSE_EVENT
   (Clicked 'X' on system menu) to avoid irregular
   shutdown with SETCANCEL( .F. )

   REQUEST HB_GT_WIN_DEFAULT
   ANNOUNCE HB_GTSYS
   PROCEDURE Main()
  SetCancel(.F.)
  ? "Click [X] Not close windows"
  WAIT
   RETURN

Modified Paths:
--
trunk/harbour/src/rtl/gtwin/gtwin.c

--- .patch
Index: gtwin.c
===
--- gtwin.c (revision 14052)
+++ gtwin.c (working copy)
@@ -563,7 +563,9 @@

   case CTRL_CLOSE_EVENT:
   case CTRL_BREAK_EVENT:
- s_bBreak = HB_TRUE;
+ /* Avoid irregular shutdown if SetCancel( .F. ) [jarabal] */
+ if( hb_setGetCancel() )
+s_bBreak = HB_TRUE;
  bHandled = TRUE;
  break;

---

--
Xavi

El 03/03/2010 23:09, smu johnson escribió:

Hi,

I'm trying to write a simple Hello World app that does something like a
WAIT command and maybe calls a function if I click the X button for a
GTWIN app.  I have no idea if this is even possible, as I have grepped
the entire harbour src .zip file contents for some hints.  In the few
results for CTRL_CLOSE_EVENT I don't really see anything relevant that
can like.. set up a call hook function or anything.  I'm totally lost.

Any hints greatly appreciated.

--
smu johnson mailto:smujohn...@gmail.com>>


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

>> I have it in mind to try that 'one of these days', meaning probably within 
>> your lifetime. ;-)
> 
> It would be nice if this could be chewed 
> into HB_GTI_NOTIFIERBLOCK support for GTWIN, 
> at least for close events that is.
> 
> Any results of your experiments is useful, 
> so just take your time. My lifetime is not very 
> relevant here, that of Harbour is :)
> 
> [ I made a little test and the event is 
> caught though and even the callback works, 
> but at this point it becomes unstable, no 
> input device works and it crashes then. ]

The other problem is that there doesn't seem 
to exist a way to _prevent_ the close from 
happening. So in case of HBWIN, the notifier 
block will be called, and it can do non-interactive 
cleanup work, but that's pretty much it.
This may be useful also, but not the same as 
in GTWVT (IOW return value of notifier block 
is always ignored in GTWIN).

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

Hi Paul,

>> With GTWIN I still have to see proof that
>> it's technically possible to catch close
>> events like that, until then I assume it's
>> not possible, and for sure it's not implemented
>> in Harbour.
> 
> I have seen some code posted on the Clipper forum that I hope I captured 
> concerning fullscreen/Windows from code in a cmd shell.  Given that, it 
> should be possible to work out the events for the close button. (I think)
> 
> I have it in mind to try that 'one of these days', meaning probably within 
> your lifetime. ;-)

It would be nice if this could be chewed 
into HB_GTI_NOTIFIERBLOCK support for GTWIN, 
at least for close events that is.

Any results of your experiments is useful, 
so just take your time. My lifetime is not very 
relevant here, that of Harbour is :)

[ I made a little test and the event is 
caught though and even the callback works, 
but at this point it becomes unstable, no 
input device works and it crashes then. ]

--- .dif
Index: gtwin.c
===
--- gtwin.c (revision 14049)
+++ gtwin.c (working copy)
@@ -82,6 +82,7 @@
 #include "hbapiitm.h"
 #include "hbapierr.h"
 #include "hbwinuni.h"
+#include "hbvm.h"
 
 #include "hbapicdp.h"
 
@@ -149,6 +150,7 @@
 #define HB_GTSUPER   (&SuperTable)
 #define HB_GTID_PTR  (&s_GtId)
 
+static PHB_GT  s_pGT = NULL;
 static HB_BOOL s_bOldClosable;
 static HB_BOOL s_bClosable;
 static HB_BOOL s_bSpecialKeyHandling;
@@ -549,6 +551,27 @@
 
 /* *** */
 
+static int hb_gt_win_FireEvent( PHB_GT pGT, int nEvent )
+{
+   int nResult = 0; /* Unhandled */
+
+   if( pGT->pNotifierBlock )
+   {
+  if( hb_vmRequestReenter() )
+  {
+ PHB_ITEM pEvent = hb_itemPutNI( NULL, nEvent );
+
+ nResult = hb_itemGetNI( hb_vmEvalBlockV( pGT->pNotifierBlock, 1, 
pEvent ) );
+
+ hb_itemRelease( pEvent );
+
+ hb_vmRequestRestore();
+  }
+   }
+
+   return nResult;
+}
+
 static BOOL WINAPI hb_gt_win_CtrlHandler( DWORD dwCtrlType )
 {
BOOL bHandled;
@@ -562,6 +585,15 @@
  break;
 
   case CTRL_CLOSE_EVENT:
+ if( s_pGT )
+ {
+s_bBreak = ( hb_gt_win_FireEvent( s_pGT, HB_GTE_CLOSE ) == 0 );
+bHandled = TRUE;
+ }
+ else
+bHandled = FALSE;
+ break;
+
   case CTRL_BREAK_EVENT:
  s_bBreak = HB_TRUE;
  bHandled = TRUE;
@@ -801,6 +833,7 @@
/* AllocConsole() initializes standard input, standard output,
   and standard error handles for the new console. [jarabal] */
/* Add Ctrl+Break handler [vszakats] */
+   s_pGT = pGT;
SetConsoleCtrlHandler( hb_gt_win_CtrlHandler, TRUE );
 
HB_GTSUPER_INIT( pGT, hFilenoStdin, hFilenoStdout, hFilenoStderr );
---

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

2010-03-03 Thread Paul Tucker


Victor,


With GTWIN I still have to see proof that
it's technically possible to catch close
events like that, until then I assume it's
not possible, and for sure it's not implemented
in Harbour.


I have seen some code posted on the Clipper forum that I hope I captured 
concerning fullscreen/Windows from code in a cmd shell.  Given that, it 
should be possible to work out the events for the close button. (I think)


I have it in mind to try that 'one of these days', meaning probably within 
your lifetime. ;-)


Paul 


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage

2010-03-03 Thread smu johnson

Wow this test is really cute.  I'll be poking around with this.  Thanks a
ton!

On Wed, Mar 3, 2010 at 2:21 PM, Viktor Szakáts  wrote:

> > I'm trying to write a simple Hello World app that does something like a
> WAIT command and maybe calls a function if I click the X button for a GTWIN
> app.  I have no idea if this is even possible, as I have grepped the entire
> harbour src .zip file contents for some hints.  In the few results for
> CTRL_CLOSE_EVENT I don't really see anything relevant that can like.. set up
> a call hook function or anything.  I'm totally lost.
> >
> > Any hints greatly appreciated.
>
> Use GTWVT and HB_GTI_NOTIFIERBLOCK (see: tests\wvtext.prg)
>
> With GTWIN I still have to see proof that
> it's technically possible to catch close
> events like that, until then I assume it's
> not possible, and for sure it's not implemented
> in Harbour.
>
> Brgds,
> Viktor
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
smu johnson 
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hb_gt_win_CtrlHandler usage