Same old stuff, but gathering it all up into libraries. Well, old but with the added new stuff like hardware acceleration to add some effects in SCREEN 0 that were not possible in the old days.
1) Left click on any character in the sample text input box at bottom of demo screen.
2) Right click.
3) Hover the mouse near the top of the popup, depress the left mouse button, and start dragging the window around the screen.
There are rabbit holes everywhere to fix this, but nothing I've found is straight forward enough to bother with. Ironically _SCREENIMAGE could be used with other statements to make a temporary screen under the popup, which is a full hardware image. That would allow for a software popup with a hardware opaque shadow to correctly display. The problem is _SCREENIMAGE is dependent on exact coordinates of the QB64 window, minus the title bar. It would probably require API additions to track that, and my hunch is the screen contents wouldn't be perfectly aligned anymore, but really, really close. After the popup is closed, a copy of the old software screen would be put back, and the hardware images would return as the program cycles through their display statements. I wish _COPYIMAGE had this ability to capture the QB64 window contents in SCREEN 0 like _SCREENIMAGE does for the desktop.
Edit Update: Popup shadow works great now! I was able to incorporate Steve's _SaveImage idea.
Pete
- Give Bill enough string and he'll tunnel himself.
(03-30-2025, 06:39 AM)Pete Wrote: No luck getting _copyimage to work in SCREEN 0 to pick up a screen with both the hardware and software images present. So no way to make copy into a hardware only image. If I could do that, situation solved.
Not *today*, but I mentioned it to @a740g and he didn't seem to think it'd be that hard to work into the language. You *could* already do a work around by saving to disk with _SaveImage (it works with SCREEN 0), and then _LOADIMAGE that saved image, and then _COPYIMAGE that software image to hardware.
That's basically the process we'd implement behind the screens (though with it all being mem streams and no disk read/writes required), to add that functionality to _COPYIMAGE(text_screen_handle, 33). It seems pretty straight forward, and if you can wait until the next release, it may be something that we can add into the language by then for added flexibility with that command. It'd be SLOW as you'd convert from text to software to hardware, but it should be *possible*, rather than just tossing that error that you see now.
Today, the solution would be:
_SaveImage "foo.png"
temp = _LoadImage("foo.png", 32)
hw = _CopyImage(temp, 33)
_FreeImage temp
Once we expand the functionality, it'd just be:
hw = _CopyImage(0, 33)
So... you can do a work around yourself, or.. wait for updates and expansions which may, or may not, be soon(tm).
03-30-2025, 02:34 PM (This post was last modified: 03-30-2025, 02:43 PM by Pete.)
Well once the image is loaded, it wouldn't be anymore time than using the blank underlay, so that would only give us the one draw back of not being able to easily update that background image if a process, say a stupid clock with a jackass second counter was running on that page. Well, that would just mean adding an update trigger, but I bet that would make dragging the popup a bit glitchy. Or... just convert the clock readout to mem and display it as a hardware image. Man, this mixing screens is a lot of thought and planning. Very procedural in nature. It makes me remember why, as much as I like to fly, I never took lessons. Too impetuous. Maybe when AI gets better I'll give it a go. You know, when I can just jump in the cockpit and say...
FLY MOTHER ****ER!
Pete
PS Did you guys have a look at what I thought might be a bug in the _SCREENIMAGE output?
The "Hello World" part made a duplicate appearance that shouldn't be present in the upper right corner.
Quote:That's not possible, as QB64(PE) supports only one physical window per program. However, as finally the contents of a window is just an image, and we can create as many images as our memory allows you could simply go a master/slave approach.
You have a master program which creates and manages the images and react to inputs and a slave program which can be run multiple times . . .
Thanks for the explanation! The master/slave thing is too complicated for me, so it doesn't work.
IMHO a master/slave structure is more complex,
when I was developing my windows system I used a simple stack structure, in the main I got the inputs (Keyboard & mouse) and the user action went to the window that was at the top of the stack. So the system must manage the stack and let interact the window on the top with the user.
Surely the system can be enpowered with inputs that let navigate quickly from a window to another adjourning the position of the windows in the stack. Take as example the Alt+Tab that let you navigate among the different open window in Windows.
moreover if there are uncovered areas of different windows the pointer of mouse can activate the window pointed (it goes to the top of the stack and it is showed wholly).
Quote:1) Make the popup a hardware image and keep the default display order. I explained earlier this is a pain because with even just one menu, you have to make and assemble multiple parts to get a color difference as the menu item are sometimes usable (normal black text) or not usable (grey text). Now if you are also making multiple menus, like the QB64 IDE, this would get tedious and time consuming, fast.
don't be so imperative! The work has made by software not by hand of coder!
Each menu becomes a hardware image... if a menu has 2/3 options activable you use 3-4 hardware images (1 for standard with no option activated, 1 with each option activated... copy paste and cut are cohoperative and not exclusive!
Instead if you make a project with multiple indipendent activable options I think you love hard workd and you need a hard numbero of hardware images!)
take a look here hardware images and screen 0 and here hardware images screen 0 and alpha channel
Yeah, I realized that just yesterday. Mentioned it in the other thread just awhile ago. All I need to do is draw the popup once to a graphics window each time one is opened. That's much easier. It still doesn't get me past the popups with text input. I really want to keep those as software popups.
I usually give myself a simmering down phase before I jump the gun and code. If not, I'd already be half way done with piecemeal hardware menus before I woke up and realized I worked my ASCII off for nothing. Well, others would have a good laugh over it... so, on the bright side, there's always that!
