You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
i told, first of all, about "ddt".
i like to make hot keys and to use combinations, which windows simply is not able to recognize.
(dos school).
for such purpose it's possible to use a code, similar posted http://www.powerbasic.com/support/pb...ead.php?t=2278
also hook allows to refuse from some undesired events.
but what do you name api-based apps ?
sdk-style ? don't see difference with ddt in such questions.
apps without visual form ?
------------------
[this message has been edited by semen matusovski (edited july 11, 2000).]
Personally, I do not recommend the use of hooks unless there is no other alternative.
This is the very first thing that Win32.HLP says about hooks:
Hooks tend to slow down the system because they increase the amount of processing the system must perform for each message. You should install a hook only when necessary, and remove it as soon as possible.
In fact, if you click on "About Hooks" that is all it says.
Mike, depending on your choice of coding techniques, you should be able to intercept all of the keystrokes that you need. The Windows and DDT dialog engines automatically handle things like the Tab/BackTab key, hotkeys like the underlined first letters of labels, and "accelerators" such at the Ctrl-keys that are used on pulldown menus. You can intercept them if you want to, but it is usually best to work within the "normal" framework, in order to produce an interface that acts "normally".
You almost never want to to intercept 100% of the keys that the user may press, or you end up interfering with the way they expect Windows to work (Alt-Tab, Ctrl-Esc, Shift-Insert, etc. etc. etc.)
If you can be more specific about what you want to do, I'm certain that we can give you some suggestions.
What do you want your program's main window to look like? I assume that it will list the selections like "A" and "B" in some manner.
Pushbuttons? If so, all you have to do is use the & prefix to define hot-keys like this...
Code:
&Add
&Bitmap
&Cut
&Delete
&Edit
&File
e&Xit
The prefixed letter will be underlined on the pushbutton, and when the user presses a key it will look (to your program) as if the corresponding button had been clicked.
Scott Turchin
MCSE, MCP+I http://www.tngbbs.com
---------------------- True Karate-do is this: that in daily life, one's mind and body be trained and developed in a spirit of humility; and that in critical times, one be devoted utterly to the cause of justice. -Gichin Funakoshi
That is great news that a single key will
allow branching.
What if the user is in an input field?
I would like to be able to access records
at the keystroke level:
Example
Keystroke 1 N - name search
First client alphabetically is displayed
Keystroke 2 P - first client starting with P displayed
Keystroke 3 I - first client starting PI displayed
Scott, we were posting at the same time.
------------------
[This message has been edited by Mike Doty (edited July 11, 2000).]
Eric --
Hooks ... Slowly ..
If To talk about similar WH_CALLWNDPROC - agree.
If about WH_KEYBOARD - Not (how much keys it possible To press per second ?)
Mike --
GUI allows to do the same as Inkey$.
There is direct analog of Inkey:
WM_CHAR event + WM_KEYUP/WM_KEYDOWN.
You can play with such code (see caption)
Code:
#Compile Exe
#Register None
#Dim All
#Include "Win32Api.Inc"
CallBack Function DlgProc
If CbMsg = %WM_DESTROY Then PostQuitMessage 0
End Function
Function PbMain()
Local Msg As tagMsg, hDlg As Long, i As Long
Dialog New 0 ,"", , , 200, 100, %WS_CAPTION Or %WS_SYSMENU To hDlg
Control Add TextBox, hDlg, 101, "", 10, 10, 170, 12
Control Add TextBox, hDlg, 102, "", 10, 30, 170, 12
Control Add ComboBox, hDlg, 301,, 10, 65, 170, 100, %CBS_DROPDOWNLIST Or %WS_TABSTOP
For i = 1 To 10: ComboBox Add hDlg, 301, "Line"+ Str$(i): Next
ComboBox Select hDlg, 301, 1
Dialog Show Modeless hDlg Call DlgProc
While GetMessage(Msg, %NULL, 0, 0)
If Msg.message = %WM_CHAR Then SetWindowText hDlg, "ASCII=" + Chr$(Msg.wParam) + " " + _
"HEX=" + Hex$(Msg.wParam)
If IsDialogMessage(hDlg, Msg) = %FALSE Then _
TranslateMessage Msg: DispatchMessage Msg
Loop
End Function
That's up to you! Normally, any key that the user presses will affect the field that is being edited. What would you want to happen if the user pressed "A" in an input field?
You can set up the Tab key, Ctrl-keys, and Alt-keys to jump around from field to field, or to trigger a button.
The most common technique is to tell the input field (an Edit Control) to ignore the Enter key, so that it is passed to the default button. Or the user can Tab to a button, or use the button's Alt-key.
For example, if no Edit Control has the keyboard "focus", pressing G might trigger your Go button. If an Edit Control has the focus then pressing G would type a G in the field, but pressing Alt-G would still trigger the Go button.
Yes, sometimes you have to resort to a technique called "subclassing" to get all of the keystrokes you need, but in my experience, when you are creating a "normal" GUI, that is rarely necessary.
I do not wish to debate the benefits and penalties that are involved with using hooks. If you obtain acceptable results, great! But I believe what Win32.HLP has to say about them. The warnings in the Microsoft docs do not make an exception for keyboard hooks.
Please be advised that the technique that is used in the code that Semen posted is not officially "sanctioned" by PowerBASIC. It mixes DDT code and API code in a way that PowerBASIC does not officially support, and that may or may not work with future versions of the compiler. (At least, that is the last official word that I have from PowerBASIC support.)
That being said, it is possible to do the same thing using other techniques. You could write your code without using DDT, or perhaps somebody will post a 100%-DDT technique.
Or you can use it at your own risk, as many people do! As you can probably tell, I lean toward the "conservative" side when it comes to things like this, but I don't know how you feel about them.
The real point of all of this (as I see it) is that it is definitely possible to do what you want to do.
Eric,
Sure like the way it works and really appreciate the help.
It is at the core of my system so I hope it is supported
in the future. I'm going with it because it allows
a lot of things to be done in the background based
upon any keystroke.
So can other techniques! All I'm suggesting is that before you use an unconventional technique for something that you say is "the core" of your system, use the BBS's Search feature to look for...
Code:
WM_CHAR
WM_KEYDOWN
SUBCLASS
SUPERCLASS
...to familiarize yourself with all of the issues and the range of solutions that are available.
WinLIFT or DV32 have functions that will allow you to trap each keystroke.
Then you can build your own input form for database purpose if this is what you want.
You can even setup minimum/maximum values for numeric input fields.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Tweet
[email protected][email protected]</A>
Comment