found big bug in version 9.00 graphics

[Michael Mattias]

Old FARTS often make better SWAGs than do NEWBIES

[Rodney Hicks]

I have to believe Mr. Zale would rather spend his money on one ten-minute update of the help file than on the ten or twenty or thirty two-minute phone calls or emails his support department would never have to handle to answer the same question if the info "before using GRAPHIC WAITKEY$ be sure the keyboard focus is set to that graphic control first" had been in the help file.

I cannot help but concur here. Since you put it that way, and I will send one in within 24 hours.

Just a little more playing before I do.

[Dave Biggs]

Graphic Waitkey$ in a control

It seems that GRAPHIC WAITKEY$ is a somewhat Blocking statement and that it is probably better to have it operate in it's own thread.
This code works for me ..

#Compile Exe
#Dim All
#Include "WIN32API.INC"
#Include "COMMCTRL.INC"
 
%GFX_TEST       = 1001
%BTN_ACTIVATE   = 1002
%LBL_LABEL1     = 1003
 
Function PBMain()
 Local hDlg  As Dword
  InitCommonControls
 
  Dialog New 0, "Graphic WaitKey$ test", 264, 114, 199, 103,  %WS_CAPTION Or %WS_SYSMENU, To hDlg
  Control Add Graphic, hDlg, %GFX_TEST, "", 40, 10, 100, 50, %WS_CHILD Or %WS_VISIBLE Or %WS_BORDER Or _
    %SS_NOTIFY
  Control Add Button,  hDlg, %BTN_ACTIVATE, "Keys to GFX", 130, 70, 50, 15
  Control Add Label,   hDlg, %LBL_LABEL1, "To enter text, 1st click the GFX or ->", 10, 74, 125, 10
 
  Dialog Show Modal hDlg, Call MainProc
End Function 
'------------------/PBMain
 
CallBack Function MainProc()
 Static hThread As Long
 Local lRes As Long
  Select Case As Long Cb.Msg
 
    Case %WM_COMMAND
      Select Case As Long Cb.Ctl
        Case %GFX_TEST
          If Cb.CtlMsg = %STN_CLICKED Then          ' direct activation (gives focus too)
            If hThread <> 0 Then
              Thread Status hThread To lRes
              If lRes = &H103 Then Exit Function    ' thread running already
            End If
            Thread Create GFX_Keys(Cb.Hndl) To hThread
          End If
 
        Case %BTN_ACTIVATE                          ' "remote" activation
          If Cb.CtlMsg = %BN_CLICKED Or Cb.CtlMsg = 1 Then
            Dialog Post Cb.Hndl, %WM_COMMAND, MAKDWD(%GFX_TEST, %STN_CLICKED), GetDlgItem(Cb.Hndl, %GFX_TEST)
            SetFocus(GetDlgItem(Cb.Hndl, %GFX_TEST))  ' need focus for keyboard input
          End If
      End Select
 
    Case %WM_SYSCOMMAND
      If (Cb.WParam And &HFFF0) = %SC_CLOSE Then
        Thread Close hThread To lRes
        Graphic Detach
        Dialog End Cb.Hndl
      End If
 
  End Select
End Function 
'------------------/MainProc
 
Function GFX_Keys(ByVal hWnd As Long) As Long
 Local TempStr As String, x As Long 
  Dialog Get Size hWnd To x, x       ' * insurance :)
  Graphic Attach hWnd, %GFX_TEST
  Graphic InKey$ To TempStr          ' Clear keyboard buffer
  Do
    Dialog DoEvents 1
    Graphic WaitKey$ To TempStr      ' wait until key is pressed
     'WinBeep 400, 50
      Select Case TempStr
        Case ""
          Exit Do
        Case Chr$(27)
          Exit Do
        Case " " To "~"
          Graphic Print TempStr;
        Case Chr$(13)
          Graphic Print
        Case Else 
          Iterate Loop
      End Select
  Loop While x <> 0                  ' *
 Graphic Detach
End Function 
'------------------/GFX_Keys

[Michael Mattias]

>It seems that GRAPHIC WAITKEY$ is a somewhat Blocking statement....

Works as documented?

> and that it is probably better to have it operate in [its] own thread

Application-specific?

[Dave Biggs]

>Works as documented?

GRAPHIC WAITKEY$ waits for a key to be pressed.

>Application-specific?

Is the Pope a catholic?

[Anthony Giambalvo]

... (started way before 8.05 came out) ...

8.05? I missed that somehow.

[Rodney Hicks]

Dave, you've melded the two issues together in a working example. GRAPHIC WINDOW and GRAPHIC CONTROL. I notice that the focus still needs to be established in your version.

Under GRAPHIC ATTACH the documentation states:

All further graphic operations will be directed to this target until another GRAPHIC ATTACH

IMO this implies that the focus for the GRAPHIC WAITKEY$ is already established, whereas in practice the GRAPHIC SET FOCUS seems to be required.

At least nobody tried this with the other graphic target, the BITMAP, yet.

[Michael Mattias]

IMO this implies that the focus for the GRAPHIC WAITKEY$ is already established, whereas in practice the GRAPHIC SET FOCUS seems to be required.

I would say it does not imply that at all. Just because you want to ATTACH to a graphic control does not mean you want to set the keyboard focus there... e.g., this might be some kind of 'display only' graphic control which is being updated as diffferent keys are typed or the user is using the keyboard to turn on/off checkboxes.

However, the doc should tell you to set the focus to the control of interest before using GRAPHIC WAITKEY$

[Dave Biggs]

Rod,
My example doesn't have a Graphic Window, just a Graphic Control added to a regular dialog.

The docs could (always?) be more specific but it's really a bit of a given that if you want the results of keystrokes to show up in a particular control then the focus for keyboard input needs to be directed to that control first?

I found that programatically activating the WaitKey$ thread by simulating a click on the control didn't set the keyboard focus there, unlike a 'real' click, hence the extra SetFocus statement in the BTN_ACTIVATE case code.

BTW there is a specific "Graphic Input Flush" statement that could be used in place of Graphic InKey$ in the WaitKey$ thread. - I'm still working through the new commands

(Wish there were a few code samples for them..)

[Rodney Hicks]

Under GRAPHIC ATTACH the documentation states:
Quote:
All further graphic operations will be directed to this target until another GRAPHIC ATTACH

The use of the word "All" implied that to me. I just considered GRAPHIC WAITKEY$ another "graphic operation".

but it's really a bit of a given

Where is it given a bit? While someone 'a bit' more accustomed to programming might think that way, some of us that have bad memories might have to be learned at thing or two a time or two.

I'm still working through the new commands

Careful, that's how I got caught in this thread.

this might be some kind of 'display only' graphic control which is being updated as diffferent keys are typed or the user is using the keyboard to turn on/off checkboxes.

Geez, Michael, let me get through all my bad ideas before you start giving me good ones. I take that back!

Support has been sent a request for documentation change.

[Michael Mattias]

Windows (controls are windows) may individually be enabled or disabled, visible or invisible; in any process any window has a z-order position; on a system any one window may be active, foreground or active.

Keyboard focus is a system state, maintained by Windows(r), but 'settable' (within limits) by an application.

As previously disclaimed, I am not a user of the GRAPHICS features.

However, just browsing the doc it would appear to me when a Graphic (be it a graphic window or a graphic control) is ATTACHed, it is just another 'state of being' for the window.

The [GRAPHIC] ATTACHED state is, when you think about it, a program-level state maintained by your application and as such does not supersede or suspend the Laws of Windows.

Sounds reasonable, anyway.

MCM

[kevin oliverson]

thanks for the info guys but this isnt a puzzle solver, and its not a place to garnish your vast knowledge over us peons, its a forum to help people learn....

so thanks to the ones that have helpful info and shame on the ones that like to garnish their vast knowledge of life over us that are trying to learn.....

[Carlo Pagani]

Ok, I'll byte ... It took you from Sep 17th, 2008 02:27 PM to injest this...

[Chris Holbrook]

Some people like to mull things over...

[kevin oliverson]

I don't use the GRAPHIC WINDOW or GRAPHIC CONTROL, so I "have not been there."

OTOH, you, sir, are a USER: the most important input into the quality and usability of the documentation.

But it's pretty obvious to me you did not know you needed to set the keyboard focus to the "GRAPHIC CONTROL" of interest before using GRAPHIC WAITKEY$.

When I was GM of a VAR firm, I looked to our support logs as a source of inspiration: "What could have prevented this call so we never would have had to handle it?"

The vast vast majority of the time the answer was, "better documentation."

I have to believe Mr. Zale would rather spend his money on one ten-minute update of the help file than on the ten or twenty or thirty two-minute phone calls or emails his support department would never have to handle to answer the same question if the info "before using GRAPHIC WAITKEY$ be sure the keyboard focus is set to that graphic control first" had been in the help file.

If you -the customer - can't understand the documentation, it's deficient. Period.

MCM

i agree whole heartedly!!!