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,
Announcement
Collapse
No announcement yet.
Caret in a graphics screen
Collapse
X
-
The screen is far too complicated for a standard editor box, a lot of different character colours, lines, etc
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
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
Leave a comment:
-
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)
Code:#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
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
Leave a comment:
-
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
Leave a comment:
-
Thanks, yes I found the information on CreatCaret etc. on
http://msdn.microsoft.com/en-us/libr...8VS.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
Leave a comment:
-
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
Leave a comment:
-
Caret in a graphics screen
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 PBWinTags: None
Leave a comment: