10-16-2023, 06:56 PM
(10-16-2023, 03:06 PM)mnrvovrfc Wrote:(10-16-2023, 01:00 AM)James D Jarvis Wrote: 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.