found big bug in version 9.00 graphics

[Dave Biggs]

I always like to put "Dialog DoEvents 1" in loop that might need to be ended from 'outside'.
In this case it seems to be the right medicine again.

 
FUNCTION PBMAIN () AS LONG
 LOCAL hWin AS DWORD
 LOCAL Temp AS STRING
 
  GRAPHIC WINDOW "Box", 50, 50, 300, 300 TO hWin
  GRAPHIC ATTACH hWin, 0
  GRAPHIC BOX (10, 10) - (200, 200), 0, %BLUE
  DO
    DIALOG DOEVENTS 1         '<< MOD
    GRAPHIC WAITKEY$ TO Temp
    SELECT CASE Temp
      CASE ""
        EXIT DO
      CASE CHR$(27)
        EXIT DO
      CASE " " TO "~"
        GRAPHIC PRINT Temp;
      CASE CHR$(13)
        GRAPHIC PRINT
    END SELECT
  LOOP
  GRAPHIC WINDOW END
END FUNCTION

On my machine (Athlon XP Home SP2) it closes OK and is immune to nasty effects from Control keys being pressed too.
(Probably could use "SLEEP 1" instead of DIALOG DOEVENTS 1..)

[Laurence Jackson]

The more adventurous may want to try inserting a space in GRAPHICWAITKEY$ to revert to the inbuilt function.

The reason I said that is that I got a GPF when closing the window by clicking the "x" box when GRAPHIC WAITKEY$ was active (no Ctrl keys pressed). Has no-one else seen that?

If a Ctrl key is pressed, no GPF on window close but, as you say, the application keeps running.

[Rodney Hicks]

Laurence,
The DIALOG DOEVENTS seems to do the trick in your code, but neither it nor SLEEP help me out of my predicament.

My code, should someone want to see if they can spot something unorthodox:

#PBFORMS CREATED V1.51
'testier.bas
'--------------------------------------------------------------------------------------------------
' The first line in this file is a PB/Forms metastatement.
' It should ALWAYS be the first line of the file. Other
' PB/Forms metastatements are placed at the beginning and
' end of "Named Blocks" of code that should be edited
' with PBForms only. Do not manually edit or delete these
' metastatements or PB/Forms will not be able to reread
' the file correctly.  See the PB/Forms documentation for
' more information.
' Named blocks begin like this:    #PBFORMS BEGIN ...
' Named blocks end like this:      #PBFORMS END ...
' Other PB/Forms metastatements such as:
'     #PBFORMS DECLARATIONS
' are used by PB/Forms to insert additional code.
' Feel free to make changes anywhere else in the file.
'--------------------------------------------------------------------------------------------------

#COMPILE EXE
#DIM ALL

'--------------------------------------------------------------------------------------------------
'   ** Includes **
'--------------------------------------------------------------------------------------------------
#PBFORMS BEGIN INCLUDES
%USEMACROS = 1
#IF NOT %DEF(%WINAPI)
  #INCLUDE "WIN32API.INC"
#ENDIF
#IF NOT %DEF(%COMMCTRL_INC)
  #INCLUDE "COMMCTRL.INC"
#ENDIF
#INCLUDE "PBForms.INC"
#PBFORMS END INCLUDES
'--------------------------------------------------------------------------------------------------

'--------------------------------------------------------------------------------------------------
'   ** Constants **
'--------------------------------------------------------------------------------------------------
#PBFORMS BEGIN CONSTANTS
%IDCANCEL       =   2
%IDD_DIALOG1    = 101
%IDC_NEXT       = 522
%IDC_SCROLLBAR1 = 523 '*
%IDC_GRAPHIC1   = 524
%IDC_TEXT       = 525
#PBFORMS END CONSTANTS
'--------------------------------------------------------------------------------------------------

'--------------------------------------------------------------------------------------------------
'   ** Declarations **
'--------------------------------------------------------------------------------------------------
DECLARE CALLBACK FUNCTION ShowDIALOG1Proc()
DECLARE FUNCTION ShowDIALOG1(BYVAL hParent AS DWORD) AS LONG
#PBFORMS DECLARATIONS
'--------------------------------------------------------------------------------------------------

'--------------------------------------------------------------------------------------------------
'   ** Main Application Entry Point **
'--------------------------------------------------------------------------------------------------
FUNCTION PBMAIN()
  PBFormsInitComCtls (%ICC_WIN95_CLASSES OR %ICC_DATE_CLASSES OR %ICC_INTERNET_CLASSES)

  ShowDIALOG1 %HWND_DESKTOP
END FUNCTION
'--------------------------------------------------------------------------------------------------

'--------------------------------------------------------------------------------------------------
'   ** CallBacks **
'--------------------------------------------------------------------------------------------------
CALLBACK FUNCTION ShowDIALOG1Proc()
STATIC setter AS STRING
STATIC xx,yy AS LONG
  SELECT CASE AS LONG CBMSG
    CASE %WM_INITDIALOG
      ' Initialization handler

    CASE %WM_NCACTIVATE
      STATIC hWndSaveFocus AS DWORD
      IF ISFALSE CBWPARAM THEN
        ' Save control focus
        hWndSaveFocus = GetFocus()
      ELSEIF hWndSaveFocus THEN
        ' Restore control focus
        SetFocus(hWndSaveFocus)
        hWndSaveFocus = 0
      END IF

    CASE %WM_COMMAND
      ' Process control notifications
      SELECT CASE AS LONG CBCTL
        CASE %IDCANCEL
          IF CBCTLMSG = %BN_CLICKED OR CBCTLMSG = 1 THEN
            
            DIALOG END CBHNDL, 0
          END IF

        CASE %IDC_NEXT
          IF CBCTLMSG = %BN_CLICKED OR CBCTLMSG = 1 THEN
            'MSGBOX "%IDC_NEXT=" + FORMAT$(%IDC_NEXT), %MB_TASKMODAL
            'dialog doevents 1
            
            GRAPHIC ATTACH CB.HNDL, %IDC_GRAPHIC1
            GRAPHIC WAITKEY$
            SLEEP 1    'tried before and after the GRAPHIC WAITKEY$
          END IF

        CASE %IDC_GRAPHIC1

        CASE %IDC_TEXT

      END SELECT
  END SELECT
END FUNCTION
'--------------------------------------------------------------------------------------------------

'--------------------------------------------------------------------------------------------------
'   ** Dialogs **
'--------------------------------------------------------------------------------------------------
FUNCTION ShowDIALOG1(BYVAL hParent AS DWORD) AS LONG
  LOCAL lRslt  AS LONG

#PBFORMS BEGIN DIALOG %IDD_DIALOG1->->
  LOCAL hDlg   AS DWORD
  LOCAL hFont1 AS DWORD

  DIALOG NEW hParent, "testier", 275, 75, 415, 361, %WS_POPUP OR %WS_BORDER OR %WS_DLGFRAME OR _
    %WS_SYSMENU OR %WS_MINIMIZEBOX OR %WS_CLIPSIBLINGS OR %WS_VISIBLE OR %DS_ABSALIGN OR _
    %DS_MODALFRAME OR %DS_3DLOOK OR %DS_NOFAILCREATE OR %DS_SETFONT, %WS_EX_CONTROLPARENT OR _
    %WS_EX_LEFT OR %WS_EX_LTRREADING OR %WS_EX_RIGHTSCROLLBAR, TO hDlg
  CONTROL ADD BUTTON,  hDlg, %IDCANCEL, "exit", 5, 5, 50, 15
  CONTROL ADD BUTTON,  hDlg, %IDC_NEXT, " next", 195, 320, 50, 15
  CONTROL ADD GRAPHIC, hDlg, %IDC_GRAPHIC1, "", 305, 5, 100, 50, %WS_CHILD OR %WS_VISIBLE OR _
    %SS_NOTIFY
  CONTROL ADD LABEL,   hDlg, %IDC_TEXT, "", 20, 100, 340, 50

  hFont1 = PBFormsMakeFont("Lucida Console", 10, 400, %FALSE, %FALSE, %FALSE, %ANSI_CHARSET)

  DIALOG  SEND hDlg, %WM_SETFONT, hFont1, 0
  CONTROL SEND hDlg, %IDCANCEL, %WM_SETFONT, hFont1, 0
  CONTROL SEND hDlg, %IDC_NEXT, %WM_SETFONT, hFont1, 0
  CONTROL SEND hDlg, %IDC_GRAPHIC1, %WM_SETFONT, hFont1, 0
  CONTROL SEND hDlg, %IDC_TEXT, %WM_SETFONT, hFont1, 0
#PBFORMS END DIALOG

  DIALOG SHOW MODAL hDlg, CALL ShowDIALOG1Proc TO lRslt

#PBFORMS BEGIN CLEANUP %IDD_DIALOG1
  DeleteObject hFont1
#PBFORMS END CLEANUP

  FUNCTION = lRslt
END FUNCTION
'--------------------------------------------------------------------------------------------------

[Laurence Jackson]

Rod, I don't understand what you're trying to do with GRAPHIC WAITKEY$ in a callback. The result is being ignored, so its just a pause until any key is pressed. Because this is in a callback, all other dialog messages are stalled while waiting.

The DIALOG DOEVENTS does not do it in my code. I still get a GPF.

[Rodney Hicks]

The DIALOG DOEVENTS does not do it in my code. I still get a GPF.

You're right. I forgot to put the space back in GRAPHIC WAITKEY$.

Rod, I don't understand what you're trying to do with GRAPHIC WAITKEY$ in a callback.

I was just experimenting with my new toy, PBWin 9.0, which because it has so many new things, will be a new toy for months. Why in a callback? Well, the documentation doesn't say it couldn't, shouldn't be there.

The result is being ignored, so its just a pause until any key is pressed. Because this is in a callback, all other dialog messages are stalled while waiting.

But once a key is pressed the other messages should no longer be stalled, no?
I had other code in there but kept removing until I got to the cause of my dilemma.

I do like your GraphicWaitkey function, for reasons other than it works. I will be experimenting with it as well.

[Cliff Nichols]

maybe off topic...but maybe right on the $$$$$

Do you have any spyware watchers running??? (Spybot Search and Destroy for example)???

If so, then close them all, and see if the problem goes away.

And if the problem can not go away then run SysInternals "Process Viewer" and then your program, and see if your program appears as part of something else that you are not aware of at the moment????

[Rodney Hicks]

Cliff,
Do you have PBWin 9.0? If you have, did you try either of the programs? Can anyone run the programs without GPF or process still processing?

I use Avast!, hence no problems of that sort. Maybe. But not in this instance.

That link you provided does not work. Will do a search.

[Michael Mattias]

Just looking at online doc (I do not have 9x)

[GRAPHIC WAITKEY$] returns a string of 0, 1, or 2 characters that reflects the status of the keyboard buffer for the selected graphic target. A null string (LEN=0) means that there was an error, such as the case when no graphic target has been assigned with GRAPHIC ATTACH.

Why don't you add the "TO stringvar" and test to see if an error ocurred on the statement?

Untested/un-acted-upon errors cause lots of problems.

And just for the heck it try....

CONTROL SET FOCUS  CBHNDL, %IDC_GRAPHIC1

...before you issue the GRAPHIC WAITKEY$

The doc for GRAPHIC ATTACH does not say that ATTACH automatically assigns the keyboard focus to the graphic control - and I should think it should NOT do so automatically on a GRAPHIC ATTACH command. Maybe GRAPHIC WAITKEY$ sets the keyboard focus - I should think it would - but doc doesn't say that either.


MCM

[Rodney Hicks]

Why don't you add the "TO stringvar" and test to see if an error ocurred on the statement?

Because that was something I removed from the code trying to narrow down the problem.

Guess what!

CONTROL SET FOCUS CBHNDL, %IDC_GRAPHIC1

No problem. Thank you very much!!!! Don't know that I'd ever thought of that on me own.

PS
MCM Thanks for the 20000+ posts.

[Rodney Hicks]

The cure for Laurence's code is the 'GRAPHIC SET FOCUS' placed just before the DO/LOOP structure.
However, the program will not end properly if you don't use 'ESCAPE' to exit the loop, that is, if you just click on the X box.

[Laurence Jackson]

The cure for Laurence's code is the 'GRAPHIC SET FOCUS' placed just before the DO/LOOP structure.

Again, I don't see any difference in testing this here Rod.

[Rodney Hicks]

This works for me.

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG

LOCAL hWin AS DWORD
LOCAL Temp AS STRING

GRAPHIC WINDOW "Box", 50, 50, 300, 300 TO hWin
GRAPHIC ATTACH hWin, 0
'GRAPHIC BOX (10, 10) - (200, 200), 0, %BLUE
GRAPHIC SET FOCUS
DO
  'dialog doevents 1
  GRAPHIC WAITKEY$ TO Temp
  SELECT CASE Temp
  CASE ""
    EXIT DO
  CASE CHR$(27)
    EXIT DO
  CASE " " TO "~"
    GRAPHIC PRINT Temp;
  CASE CHR$(13)
    GRAPHIC PRINT
  END SELECT
LOOP
GRAPHIC WINDOW END

END FUNCTION


FUNCTION GRAPHICWAITKEY () AS STRING

LOCAL hDC AS DWORD
LOCAL Temp AS STRING

DO
  SLEEP 1
  GRAPHIC GET DC TO hDC
  IF hDC = 0 THEN
    Temp = ""
    EXIT DO
  END IF
  GRAPHIC INKEY$ TO Temp
LOOP WHILE Temp = ""
FUNCTION = Temp

END FUNCTION

This works as long as I use the 'ESC' key to exit the DO LOOP on my machine. You just can't close the program with the X box. The blue graphic box makes no difference.

By 'works', I mean it doesn't leave the process running or produce a GPF.

[Rodney Hicks]

If you place another 'GRAPHIC WAITKEY$' after 'LOOP', before 'GRAPHIC WINDOW END' you can use the X box thingy. Uhh, sometimes.

[Laurence Jackson]

I think it's fair to say that, although it's not the "bug" that started this thread, GRAPHIC WAITKEY$ has a couple of problems. I tried pointing this out to support a week or so ago, but they obviously had more important things to worry about at the time

I've also got more important things to worry about! If I need a WAITKEY function I'm going to simulate it it using GRAPHIC INKEY$, as shown in my earlier post.

[Rodney Hicks]

There may be an issue, but IMO it's a documentation issue. Before I send anything in however, I will do some more playing around with it.

[Michael Mattias]

>This works for me.

Careful.....that example is for a GRAPHIC WINDOW

The original question was about a GRAPHIC CONTROL

You'd expect - and apparently get - different behaviors.

MCM

[Laurence Jackson]

Rod introduced some stuff using a graphic CONTROL, but most of the thread (and my comments) are about a graphic WINDOW.

I don't see GRAPHIC WAITKEY$ as being very useful with a graphic control, but anyway with a control you get a chance to do some cleaning up on the WM_DESTROY message for the dialog - you don't get that chance with a graphic window.

[Rodney Hicks]

Careful.....that example is for a GRAPHIC WINDOW

The original question was about a GRAPHIC CONTROL

You'd expect - and apparently get - different behaviors.

My input into this thread started with a GRAPHIC CONTROL, and your suggestion of 'CONTROL SET FOCUS' made me wonder about the other, the GRAPHIC WINDOW, since you solved the 'CONTROL' issue for me.

The GRAPHIC WINDOW can be made to close properly(no process left running, no GPF), using GRAPHIC SET FOCUS and GRAPHIC WAITKEY$ as long as the X box thingy isn't used.(Which makes me wonder if there is some way to suppress the system menu on the GRAPHIC WINDOW.)
This to me is a horse of a different colour, as you point out, and for now I'm going back to my 'GRAPHIC CONTROL'.
I do think that a change in the documentation might be in order, but until I've played with these things enough I don't think my present suggestions would be as good as they could be, for often times getting accustomed to new things takes a wee bit more than we think.

I don't see GRAPHIC WAITKEY$ as being very useful with a graphic control,

This may depend on many things, and it's still early in the game for GRAPHIC WAITKEY$.

[Michael Mattias]

I do think that a change in the documentation might be in order, but until I've played with these things enough I don't think my present suggestions would be as good as they could be, for often times getting accustomed to new things takes a wee bit more than we think.

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

[Cliff Nichols]

Sounds like "Problem Solved" then

I gotta love it when minds collaborate and it turns out to be an easy answer

(or at least an answer that some overlooked, and some did not, but come to find out...yep, just a slip in code, but caused SUCH trouble)