Caret in a graphics screen

[Peter Simmonds]

The usual apologies if this has been covered before, but can't find anything about it in the forum.

I am planning to use the graphics window to display text. Through various GRAPHICS commands and callback that capture keyboard and mouse movements, it's possible to simulate editing the text, but for this I need a positionable caret to indicate where editing will occur. Ideally different carets (block, underline) should be available.

Can't see anything about carets in DDT. Does anyone have any ideas?

Thanks in advance

peter

PS Very new to PBWin

[Michael Mattias]

Didn't someone post code where you add an edit control as a child of a GRAPHICS WINDOW or 'CONTROL ADD GRAPHIC' control?

That would kind of address all your caret concerns, cursor movement, etc, etc etc without the need to reinvent an edit control.

DDT has no caret commands. Fortunately the Windows API does (CreateCaret() would be a good start).

However, I'd be real careful about using those with a CONTROL ADD TEXTBOX control, which may do its own caret management; instead, I'd suggest you use CONTROL ADD "Edit".... so DDT won't interfere with your caret manipulation.

MCM

[Peter Simmonds]

Thanks, yes I found the information on CreatCaret etc. on

http://msdn.microsoft.com/en-us/library/ms674848%28VS.85%29.aspx

This superimposes on the graphics screen attached to an underlying dialog, and seems to simulate a caret found in real text editing.

Luckily I have all the code for moving the caret around and editing text from PBCC days.....

Peter

[Michael Mattias]

Luckily I have all the code for moving the caret around and editing text from PBCC days.....

First of all, I think when posting questions about "the GRAPHICS commands" in the PB for WINDOWS forum, it would be useful to potential responders to indicate clearly if one is referring to a GRAPHICS window (GRAPHIC WINDOW ....) or a GRAPHICS control (CONTROL ADD GRAPHIC...).

Which begs the question... if you have a dialog, why not use an edit control (CONTROL ADD TEXTBOX ... or CONTROL ADD "edit" ....) for your text editing, and graphics controls (CONTROL ADD GRAPHIC....) for the stuff on your screen for which you'd like to use the GRAPHICS statements?

Or, perhaps describe the screen you want to create ("WHAT") and ask for suggestions about the best way to achieve your goal ("HOW")?

MCM

[Peter Simmonds]

The screen is far too complicated for a standard editor box, a lot of different character colours, lines, etc.

Actually approaching this project has led me into some conceptual difficulties with the graphics commands. The following (minimal) code illustrates the problem I have with the GRAPHIC INKEY$/WAITKEY$ or GRAPHIC LINE INPUT commands (which would be needed if I was using the graphics screen interactively)

#COMPILER PBWIN 9
#COMPILE EXE
#INCLUDE "Win32API.inc"
DEFLNG a-z
%GR_Screen = 900

GLOBAL main_handle AS LONG

FUNCTION PBMAIN () AS LONG

    DIALOG NEW 0, a$, , , 400, 200,_
    %WS_POPUP OR %DS_MODALFRAME OR %WS_CAPTION OR %WS_MINIMIZEBOX OR %WS_SYSMENU OR %WS_THICKFRAME OR %WS_CLIPCHILDREN, 0 TO main_handle

    CONTROL ADD GRAPHIC, main_handle, %GR_screen, "", 10, 10, 380, 180,
    GRAPHIC ATTACH main_handle, %GR_screen
    GRAPHIC ELLIPSE (20, 20) - (360, 160), %RED,

    DIALOG SHOW MODELESS main_handle, CALL GS_DlgProc() TO a

    GRAPHIC SET POS (50, 50)
    GRAPHIC PRINT "Hello"
    GRAPHIC WAITKEY$ a$
    MSGBOX a$


END FUNCTION

CALLBACK FUNCTION GS_DlgProc()

END FUNCTION

The program draws an ellipse on a graphics object that is attached to the main dialog. I cannot quite conceptualise how a GRAPHIC WAITKEY$ command can work if there is a callback process going on.

If I set DIALOG SHOW to MODAL, it obviously never gets as far as the GRAPHIC WAITKEY$ command until the dialog box is exited, in which case it is destroyed and you never see the Print or WAITKEY$ commands.

However if you set it to MODELESS, it runs through to the WAITKEY$ command but it then can't get past this point. If the program is closed then an invisible process still runs and has to be shut down by Task Manager.

If I put the GRAPHIC PRINT and WAITKEY$ commands before DIALOG SHOW then the program again stays invisible.

In short, where do you put the user input commands in this type of dialog? As mentioned the INKEY$ and LINE INPUT graphic commands are procedural and don't seem to fit into the windows programming environment.

Peter

[Michael Mattias]

The screen is far too complicated for a standard editor box, a lot of different character colours, lines, etc

I think perhaps you need to look at some of the stuff posted here before you say this is "too complicated."

Or maybe your thinking isn't compilicated enough: the editor box does not need to be a 'single control' ... it just has to look like one when you are done.

In short, where do you put the user input commands in this type of dialog? As mentioned the INKEY$ and LINE INPUT graphic commands are procedural and don't seem to fit into the windows programming environment

You just won one of the big stuffed teddy bears for your little lady friend.

INKEY$ and LINE INPUT do NOT fit into "the windows programming enviroment" .. at least not the GUI environment.

However, if you can use a "regular" Windows GUI window - (a dialog is one type of window) , detecting key/mouse action is a piece of cake.

Open your mind, let the sun shine in.

MCM

[Manuel Valdes]

Peter:

If your application is an stand alone program, may be you can try a GRAPHIC WINDOW instead. If you have experience with PBDOS Screen 12 programming, you will find that you can do the same and a lot more, without the limitations and constrains of the DOS environment. (Memory, screen resolution, colors, fonts, printers, etc.). Also, if you have some PBCC program you will be able to convert it to graphic with very few changes. I just converted a 2500+ lines PBCC program to run on a GRAPHIC WINDOW, with some fear regarding the speed of the screen deployment, while scrolling a 50 rows by 21 columns grid. To my surprise, the program behaves many times faster than running in the "text" console.

Regards,