Vilhelm-Ion Praisach: februarie 2016

sâmbătă, 20 februarie 2016

Intercepting CTRL+SHIFT+Enter

Some combinations are not intercepted by keypress.
Some are intercepted only by the form's keypress (like the ALT+letter) but not by the object's keypress.
Also the menu's shortcuts can be ignored (like CTRL+A).
I wrote a little more about keypress here:
https://www.foxite.com/archives/keypress-and-dodefault-for-textbox-0000412653.htm

In this case, CTRL+SHIFT+ENTER is used to run an executable as administrator.
Maybe this is the reason for not being intercepted by neither the form's, nor the object's keypress()

To intercept it, the wm_keyup message must be bind to the form's hwnd, and then the GetKeyState() function must be called.
If the highest bit of the returned value of GetKeyState() is equal to 1, then the key passed as parameter was pressed (CTRL or Shift)
I wrote a little more about binding wm_keyup message, here
http://praisachion.blogspot.ro/2015/06/detect-keyup-like-mouseup.html

Here is the solution for intercepting CTRL+SHIFT+Enter.

DECLARE integer GetKeyState IN User32 integer
#define VK_RETURN 0x0d && Enter
#define VK_SHIFT 0x10 && Shift
#define VK_CONTROL 0x11 && Control

#define VK_LSHIFT 0xa0 && Left Shift
#define VK_RSHIFT 0xa1 && Right Shift
#define VK_LCONTROL 0xa2 && Left CTRL
#define VK_RCONTROL 0xa3 && Right CTRL

PUBLIC ofrm
ofrm = CREATEOBJECT("MyForm")
ofrm.show()

DEFINE CLASS MyForm as Form
    ADD OBJECT txt as textbox && the desired object
    ADD OBJECT cmd as commandbutton WITH top = 50
    PROCEDURE Init
        BINDEVENT(This.HWnd,0x0101,This,"detectkeyup") && intercept keyup
    ENDPROC
    PROCEDURE detectkeyup
        LPARAMETERS p1,p2,p3,p4
        IF TYPE("This.ActiveControl") <> "U"
            IF This.ActiveControl = ThisForm.txt AND p3 = VK_RETURN AND BITTEST(GetKeyState(VK_SHIFT),7) AND BITTEST(GetKeyState(VK_CONTROL),7)
                * p3 = VK_RETURN && 13 enter
                * place here the desired code
                * in this sample just type to the screen which shift and control (left or right) was pressed
                ACTIVATE SCREEN
                ?BITTEST(GetKeyState(VK_LSHIFT),7),BITTEST(GetKeyState(VK_LCONTROL),7),BITTEST(GetKeyState(VK_RSHIFT),7),BITTEST(GetKeyState(VK_RCONTROL),7)
            ENDIF
        ENDIF
    ENDPROC
ENDDEFINE

Please read
https://msdn.microsoft.com/en-us/library/windows/desktop/ms646301%28v=vs.85%29.aspx
https://docs.omniref.com/ruby/gems/win32-autogui/0.5.0/symbols/Autogui::Input::VK_LSHIFT
https://msdn.microsoft.com/en-us/library/windows/desktop/ms646281%28v=vs.85%29.aspx

Related posts
http://praisachion.blogspot.com/2017/08/easter-eggs-4.html
http://praisachion.blogspot.com/2017/08/easter-eggs-3.html
http://praisachion.blogspot.com/2017/08/easter-eggs-2.html
http://praisachion.blogspot.com/2017/08/easter-eggs-1.html
http://praisachion.blogspot.com/2016/02/interceptin-ctrlshiftenter.html
http://praisachion.blogspot.com/2015/06/detect-keyup-like-mouseup.html
http://praisachion.blogspot.com/2015/01/how-can-i-prevent-undocking-docked-form.html

joi, 11 februarie 2016

Import DBF from MsOffice 2007+ (xlsx, docx) 2.1

luni, 8 februarie 2016

Unexpected behavior of a two (or more) detail band report.

Introduction
I've tried to implement the "keep lines together" and "keep with next" option from the MS Word, into a VFP Report.

Basically in a report with two detail bands, I tried to force that both two bands to be printed in the same page. If one of the two bands expands to the next page, or one band is one page, and the second band is in the next page then I force a page break before the first band.

Here is a more detailed explanation
https://www.foxite.com/archives/description-cut-0000429585.htm

As you can see, I've found a solution, by running several time the same report. Each time, one "orphan" is moved to the next page.
The entire process is repeated until no moves are performed.

The solution is detailed in the previous link .

Then I tried to do the same trick with a four detail band.
And I discovered, by mistake, an unexpected behavior.

Description
Lets have a report that has two or more detail bands, and the report is grouped by a private memory variable. The value of that variable is changed inside the report, in the AFTERBAND or the ON EXIT event of the last detail band.
If the value of the variable is changed after the first record, then the report ends right after the first record, without showing the next records of the table.
If the value of the variable is changed only after the second record (or later), the report runs without problems, and show all the data.
The report behaves normally when it has only one detail band.
Also no problems occurs when the report is grouped by a table field, not by a memory variable.

The unexpected behavior can be reproduced by this combination: two or more details band, data are grouped by a memory variable, and the value of that variable is changed inside the report, particularly in the AFTERBAND event of the last detail band. And the change happens beginning with the first record.

Attached is a test.prg with three reports.
1) the first report c1, contains only one detail band, and behaves normally.

2) the second report c2, contains two details band, and behaves unexpected

3) the third report c2_2, contains two details band, and behaves normally

Download link
The archive containing a table, the three reports and a test.prg

Vilhelm-Ion Praisach

Faceți căutări pe acest blog

sâmbătă, 20 februarie 2016

Intercepting CTRL+SHIFT+Enter

joi, 11 februarie 2016

Import DBF from MsOffice 2007+ (xlsx, docx) 2.1

luni, 8 februarie 2016

Unexpected behavior of a two (or more) detail band report.

Translate

Faceți căutări pe acest blog

sâmbătă, 20 februarie 2016

Intercepting CTRL+SHIFT+Enter

joi, 11 februarie 2016

Import DBF from MsOffice 2007+ (xlsx, docx) 2.1

luni, 8 februarie 2016

Unexpected behavior of a two (or more) detail band report.

Translate

Abonați-vă la