How can I simulate the INKEY$ and WAITKEY$ functions in programs written using Power BASIC DLL Compiler? Power BASIC Console Compiler has the functions. Jeffrey.
-
-
Loop around a call to GetKeyboardState() or maybe GetKeyState().
What exactly do you want to achieve? Are you creating DDT, API or resource-file based GUI interface for your app?
There are usually different approaches to keyboard handling in GUI programming - if you can describe your project in more detail then we can probably point you in the direction that will ensure your application has a "normal" user interface.
------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>Lance
mailto:[email protected] -
Lance, In PB/CC, I can write a program like this:
print"Stillwell Avenue"
waitkey$
print"86th Street"
waitkey$
print"Avenue U"
waitkey$
print"Kings Highway"
waitkey$
In PB/DLL, I need a function that waits for me to press a key before displaying the name of the next subway station in a text box. Jeffrey.
------------------
Comment
-
hello,
the simplest way that i can think of would be to change the “any” key to the “enter or space” key.
if you are using ddt, you can place a single button on the dialog (or place it out of view if not wanted to be seen) and assign it the id number 1. then this button will become the default button for the dialog and will be pressed whenever the user presses the enter key or the spacebar key. you can then place the necessary code into a callback function for the button.
if this will not work for you, then read up on this link showing how to trap all keyboard messages going to a dialog when using ddt.
http://www.powerbasic.com/support/pb...ad.php?t=11099
hope that helps,
colin schmidt
------------------
colin schmidt & james duffy, praxis enterprises, canada
Comment
-
Jeffrey --
If you want to use PB/DLL, you should accept GUI approach - it's necessary to process events (messages).
I remember, that when appeared VB3, I need about two monthes until I really understood this style.
DDT' variant of your sample looks approx. so:
------------------Code:#Compile Exe #Register None #Dim All #Include "Win32Api.Inc" Global hDlg As Long CallBack Function NextSt Call SelectSt End Function Sub SelectSt Static St As Long Local w As String Incr St Select Case St Case 1: w$ = "Stillwell Avenue" Case 2: w$ = "86th Street" Case 3: w$ = "Avenue U" Case 4: w$ = "Kings Highway" Case 5: MsgBox "Time to rest", %MB_ICONSTOP, "End of list": Dialog End hDlg, 1 End Select Control Set Text hDlg, 101, w$ End Sub Function PbMain Dialog New 0, "Select station", , , 100, 80, %WS_SYSMENU To hDlg Control Add Button, hDlg, 102, "Next", 25, 40, 50, 14, Call NextSt Control Add TextBox, hDlg, 101, "", 8, 10, 80, 12 Call SelectSt Dialog Show Modal hDlg End Function
Comment
-
The first and most important point is that you will have to rethink your design approach to this type of program when it comes to a GUI interface. The reason is simple: GUI applications are event driven.
Before you launch into subclassing and/or messageloop handling such as suggested by Colin, you need to get an understanding of how a GUI application is designed and how/why portions of it execute. For this we recommend a good book, such as Petzold's "Programming Windows" - se the FAQ forum for recommended titles.
The key issues is what must happen when your application "pauses" for a keypress: typically, a PB/CC program will use PRINT to display a message and then use WAITKEY$ to pause _your_ code until a key is pressed; however, a GUI application will update the display and then perform an 'EXIT FUNCTION' - it is then suspended until Windows calls your code and passes a message to tell it something has happened - like a keypress occurred or simply that the window needs to redraw itself (or the hundreds of other possible reasons).
IOW, a "callback" function for a GUI dialog/window only executes when Windows wants it to run - your code will only execute when told. In addition, your code only "listens" for the messages it wants and 'ignores' everything else.
This is quite opposite to how PB/CC and DOS applications are designed to run - once started, a traditional program does not stop until the program ends. In GUI land, you code only runs when told to, the rest of the time execution is suspended. From this we can easily determine that a different approach to interface design is required.
So, in 'psuedo code', here is the equivalent of your text-based application rewritten as a GUI app.
1. Create a dialog window and tell Windows which FUNCTION will receive notification messages about the window (the CALLBACK function)
2. add a static text control to give the user some visual feedback, and Set the initial text for the control (the 1st subway station name)
3. Create a button for the user to press to signal the program to 'advance' the text display, etc, and finally we will store the index number of the subway station that is currently displayed in either a STATIC or a GLOBAL so we can update the index number when handling future messages.
4. Suspend. Our code stops running until the a 'message' is received from Windows because something happened (or is about to happen), for example, a button was clicked, or the window needs to be repainted, etc
5. Upon receipt of a message, check the message value to see if it is a message we are expecting or want to handle ourselves.
6. if it is not a message we want, we 'ignore' the message and stop execution again, per #4 above.
7. If we get a 'wanted' message, we react according to the message. For example, the user clicked on a button, so we may want to update the text in the text control. Otherwise, we may choose to terminate the application, or...
8. Reenter the suspended state per #4 above
Maybe I should have said that this was more like a "flowchart" than psuedocode
As you can see, the internal design concepts of a GUI application are quite different to PB/CC and DOS program design.
Another of the key differences is that you have to keep track of the "state" of things between messages. For example, your sample DOS code has a list of 4 text messages. In a GUI app, you'd need to use a STATIC or a GLOBAL variable to store a number which represented the message number that you were up to. If this was not done, then your code would not know which was the correct message to display next.
Now we get to the more complicated issue - keystroke processing. In the WIMP's (Windows, Icons, Menu's and Pointers) philosophy of Windows, asking the user to "press any key" is just not cricket. Instead, you would ask the user to click on a button, or use the ENTER key to trigger the default button of the dialog, etc.
When you redesign your DOS code into GUI code, you need to update the design philosophy to maintain the consistency of the Windows GUI interface for Windows applications.
Now if you want to deviate from this philosophy, go right ahead - we won't stop you - but - your app will behave in a "nonstandard" way - some people may like it, some won't.
{rant mode OFF}
------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>Lance
mailto:[email protected]Comment
-
By the time I'd written the above message, Semen wrote a small app for you - you will note that his code exactly mirrors my points above. Well done Semen! (there was not even any collaboration!)
That said, Jeffrey, you should still do yourself a favor and beg, borrow or buy a copy of 'Petzold' - it will do you the world of good!
------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>Lance
mailto:[email protected]Comment
-
Semen, Thank you very much for the code. Jeffrey.
Originally posted by Semen Matusovski:
Jeffrey --
If you want to use PB/DLL, you should accept GUI approach - it's necessary to process events (messages).
I remember, that when appeared VB3, I need about two monthes until I really understood this style.
DDT' variant of your sample looks approx. so:
<font face="Courier New, Courier" size="3"><pre>
#Compile Exe
#Register None
#Dim All
#Include "Win32Api.Inc"
Global hDlg As Long
CallBack Function NextSt
Call SelectSt
End Function
Sub SelectSt
Static St As Long
Local w As String
Incr St
Select Case St
Case 1: w$ = "Stillwell Avenue"
Case 2: w$ = "86th Street"
Case 3: w$ = "Avenue U"
Case 4: w$ = "Kings Highway"
Case 5: MsgBox "Time to rest", %MB_ICONSTOP, "End of list": Dialog End hDlg, 1
End Select
Control Set Text hDlg, 101, w$
End Sub
Function PbMain
Dialog New 0, "Select station", , , 100, 80, %WS_SYSMENU To hDlg
Control Add Button, hDlg, 102, "Next", 25, 40, 50, 14, Call NextSt
Control Add TextBox, hDlg, 101, "", 8, 10, 80, 12
Call SelectSt
Dialog Show Modal hDlg
End Function
</pre></font>
------------------
Comment
-
Lance, I have the big fat book but I think that I couldn't understand it. Jeffrey.
Originally posted by Lance Edmonds:
By the time I'd written the above message, Semen wrote a small app for you - you will note that his code exactly mirrors my points above. Well done Semen! (there was not even any collaboration!)
That said, Jeffrey, you should still do yourself a favor and beg, borrow or buy a copy of 'Petzold' - it will do you the world of good!
------------------
Comment
Comment