Help a lazy developer!

[James D Jarvis]

_PRINTSTRING(column, row), textExpression$[, imageHandle&][, COLOR]   

oh yeah, this would be great. I wouldn't have to write my own custom commands to do this,

[mnrvovrfc]

I am an advocate for pedantic coding, the source code should leave nothing for guesswork, suppose someone not familiar with QB64's lazy options tries to decipher your code?

I sort of fully agree with this.

A long time ago, the authors of Freebasic decided to decorate their graphics functions with optional image handle parameter. But I really hate how their `POINT()` came out in particular. It's the third parameter, which could be omitted, but that's not my point. Why the hey, for example with `GET` and `LINE` it's the first parameter if it must be put down?

Otherwise it's not as much a question of laziness as it is of convenience.

[mnrvovrfc]

May I ask: If we can have output directing to image handles... why not another window?

It would make better sense if it were possible to use this programming system to create an application such as Libre Office, which has the ability to contain windows within its own main window. Also support "cascade", "tile" and other options making the "big shell" behave like an independent desktop.

Can a QB64 program display two windows at the same time? Doesn't `SCREEN` work on one window at a time? If not then this request for window handles instead of image handles is pointless. Might have to dig deep into Windows API to have multiple windows working in one program which will have to be run through Wine to make it compatible with Linux, which is sloppy. Then what about MacOS?

[James D Jarvis]

May I ask: If we can have output directing to image handles... why not another window?

It would make better sense if it were possible to use this programming system to create an application such as Libre Office, which has the ability to contain windows within its own main window. Also support "cascade", "tile" and other options making the "big shell" behave like an independent desktop.

Can a QB64 program display two windows at the same time? Doesn't `SCREEN` work on one window at a time? If not then this request for window handles instead of image handles is pointless. Might have to dig deep into Windows API to have multiple windows working in one program which will have to be run through Wine to make it compatible with Linux, which is sloppy. Then what about MacOS?

Not saying I'm a hero and can solve this but... I've written programs with more than one window on the Mac.. Granted it was a darned long time ago now but it surely hasn't become more difficult than it was 20 years ago.  The thing is the model the QB64 programmer sees doesn't have to be the same as that the compiler actually uses. Something would have (in effect) keep track of where a handle is, is it displaying in a screen  or is it in memory. Updating an image canvas is updating an image canvas.... if you have direct access to it. I imagine the mouse routines would be the biggest hurdle for updating to such a scheme.  
We have the means to do decent dialog boxes currently and we can also make tiled/cascading displays with the tools we have on hand in QB64 currently (again due to those image handles working as they do). Just brought it up because if anyone is planning to expand the capability of output and display commands this might be a good time to eyeball the possibility of multiple windows.

[bplus]

Multiple Screens (MS)? vince did a start to MS and (drawing a blank... guy who has a corner but hardly used it did or is working on MS) in that corner! Keybone

Wouldn't the same be accomplished by opening multiple QB64 apps?
hmm...

With MS, you'd have access to all the intimate details the other open screen has going on ie sharing data.

Well certainly a monster of a programming task!

Or create QB64 apps capable of sharing it's internals with other QB64 apps, that sounds easier.

What are legit needs for MS ie actual need for 2 or more screens to be up?
I did a stand alone GUI Dialog box for getting a pathed Filename that your program can shell and do, MS or NOT MS?
Actaully that approach may make one say, "Who needs librarys?" Just build a bunch of Dialog apps ;-))

[TerryRitchie]

Here is a list of legacy commands I believe could benefit from either supplying a source or destination handle. Please feel free to to tell me if you believe any of these command do not need such a modification and why. A few of them may be a bit dubious.

CLS [method%][, bgColor&][, DestHandle&]

COLOR [foreground&][, background&][, DestHandle&]

LOCATE [row%][, column%] [, cursor%][, cursorStart%, cursorStop%][, DestHandle&]

POINT (column%, row%)[, SourceHandle&]

POINT({0|1|2|3})[, SourceHandle&]

PRESET [STEP](column%, row%)[, colorAttribute],[, DestHandle&]

PSET [STEP](column%, row%)[, colorAttribute],[ DestHandle&]

CIRCLE [[[STEP]]](column, row), radius%, [drawColor%][, startRadian!, stopRadian!][, aspect!][, DestHandle&]

DRAW drawString$[, DestHandle&]

GET [STEP] (column1, row1)-[STEP](column2, row2), array([index])[, offscreenColor][, SourceHandle&]

LINE [STEP] [(column1, row1)]-[STEP] (column2, row2), color[, [{B|BF}], style%][, DestHandle&]

PAINT [STEP] (column%, row%), fillColor[, borderColor%][, DestHandle&]

PRINT [expression] [{;|,] [expression...][, DestHandle&]

PCOPY sourcePage%, destinationPage%[, DestHandle&]

PUT [[[STEP]]](column, row), Array([index])[,] [[[_CLIP]]] [{PSET|PRESET|AND|OR|XOR}]][, omitcolor][, DestHandle&]

VIEW [[SCREEN] (column1, row1)-(column2, row2)[, [color][, border]]][, DestHandle&]

VIEW PRINT [topRow% TO bottomRow%][, DestHandle&]

WIDTH [columns%] [,rows%][, DestHandle&]

WINDOW [ [ SCREEN] (x1!, y1!) - (x2!, y2!)][, DestHandle&]

[bplus]

@TerryRitchie Print and Paint also mentioned if we are using your list as most complete.

[mnrvovrfc]

With MS, you'd have access to all the intimate details the other open screen has going on ie sharing data.

Well certainly a monster of a programming task!

Or create QB64 apps capable of sharing it's internals with other QB64 apps, that sounds easier.

JDJ is trying to demonstrate it right now in the topic he has open now. But it uses the clipboard to communicate among the three programs involved. So no good except for Windows. Instead of using the clipboard, use filenames and check for their existence. Even if a file has to be created with zero length. It takes a bit more effort, and a bit more wear and tear on the disk but it's the only good method without the clipboard.

Also in case a program of that type is expanded which must use the clipboard, what is going to be done about it to alert another program in the suite?

[SMcNeill]

With MS, you'd have access to all the intimate details the other open screen has going on ie sharing data.

Well certainly a monster of a programming task!

Or create QB64 apps capable of sharing it's internals with other QB64 apps, that sounds easier.

JDJ is trying to demonstrate it right now in the topic he has open now. But it uses the clipboard to communicate among the three programs involved. So no good except for Windows. Instead of using the clipboard, use filenames and check for their existence. Even if a file has to be created with zero length. It takes a bit more effort, and a bit more wear and tear on the disk but it's the only good method without the clipboard.

Also in case a program of that type is expanded which must use the clipboard, what is going to be done about it to alert another program in the suite?

Why not just open a TCP/IP channel as LocalHost and then zap it to yourself?

[TerryRitchie]

@TerryRitchie Print and Paint also mentioned if we are using your list as most complete.

Yes, PAINT, can't believe I forgot that one.

Update: wait, that is in the list I made

PRINT is not though

Update 2: Just added PRINT