EasyPtr4

[RalfR]

Perhaps the MDI/FDI driver code can be made to be a THING?

[tofro]

Perhaps the MDI/FDI driver code can be made to be a THING?

Agree that would make it way nicer to handle on SMSQ/E.

But would make it a nightmare to handle on the QL. To my knowledge, there is no generally working Thing extension for QDOS.

[Martin_Head]

Hi, It's me again. With another question.

I have written a program in EasyPtr, and compiled it with QLiberator.
I can start the program, and move it about the screen fine. But I cannot right click back into Basic.

I can CRTL-C back into Basic. And if I type something

Then right click, or CTRL-C back to my program. What I have typed into Basic disappears.

Then if I quit my program. The text reappears.

I'm sure it's something I am doing wrong with OUTLN.
How can I set this up so that I can switch in and out of my program without messing the screen up.
Other PE programs seem to be able to do it.

[desin]

please take a closer look
viewtopic.php?f=3&t=4182&p=47851#p47851

Qliberator without -nowinds ?

[dilwyn]

Not sure I fully understand the problem, but it may well be something to do with the outlining.

MDRAWing a menu normally automatically sets an outline big enough to cover the open windows of that program. If you set an outline larger than the program (e.g. for that small menu, if you have set an outline to cover the whole screen or at least large enough to cover the area of the BASIC windows), it may well be that what you are seeing when you try to right click is not necessarily BASIC. It might just be the area of the screen that the outline command has saved.

This often happens when a program has a file selection menu. Especially if using Menu Extension. File selection menus are generally larger than the main menu window for small programs, so authors try to set an outline area bigger than the program's main window, to ensure it covers the area needed for the file selection menu to work.

If the area saved by the pointer interface (by specifying a larger outline) is larger than your program's primary window, it will save whatever happens to be behind it in other words.

Assuming I've understood the problem you're having correctly, there is no easy way around this other than to ensure your primary window is the size of the outline, otherwise you'll get unwanted background saved and restored.

EDIT: Sorry, my reply crossed with Desin's reply.

[tofro]

Yep, your OUTLN is definitively set to the whole screen. That lets PE save everything (even the 'background' which is actually SBASIC) because your program thinks "belongs to me".

This can either happen because you have set the OULTN explicitly (then remove/adjust just this) or because QLIberator has carried over your SBASIC window settings into the compiled program (Remember, the first window opened by a program is its primary and sets the outline - And such compiled-in windows are opened before your menu, so your menu is in fact a secondary). If the latter is the case, then compile again with "-nowinds" to not carry over the SBASIC windows into the compiled program.

I tend to always do that with compiled programs, (use '-nowinds', and open all your screen channels explicitly in the program using FOPEN), because you can run into other problems as well - for example if someone wants to run your program on a screen big enough for your menu, but smaller than your set outline, it simply won't run, becouse your current outline might not fit on other peoples' screens). Opening your own windows also has the added benefit that you don't mess up your SBASIC windows when testing interpreted.

If you need more screen real estate (for example for a file selector), you can always set a temporary OUTLN, execute your bigger menu, then switch back to the minimum.

[RalfR]

Quite right, this is the best you can do.

[Martin_Head]

Thanks for the advice. I will have a play.

I do use QMENU with my program, and I found that if I have an Outline the size of my program. Then QMENU does not display, and gives a small text input window.
If I don't have an Outline at all, my program is stuck inside the SBASIC window.
Should I use the MDRAW channel number for the OUTLN command, or the #0, that I am using at the moment. I know the -NOWINDS won't open #0 for me.

[desin]

another example
https://www.theqlforum.com/viewtopic.php ... 397#p45397

[Martin_Head]

another example
https://www.theqlforum.com/viewtopic.php ... 397#p45397

Thanks, I will have a look at this.

I tried the demo_obj program in vd.zip yesterday, and it did not like running. Threw up lots of errors. But the demo_bas program ran. And gave me the same effects that I see in my program.

I tried -nowinds, without any OUTL command. Which fixes the job switching/screen saving problem. But FILE_SELECT$ gets upset because my programs window is not big enough for FILE_SELECT$.

I tried to reset OUTL before calling FILE_SELECT$, as suggested. But got mixed results, and errors. (the EasyPtr manuals states that OUTL is not possible if there is already a working definition for the channel)

I did at one point get something that kind of worked in SBASIC, but threw up an error when run compiled with QLib. Probably something to do with inheriting an outline from SBASIC.

By the way, Is there any difference between the EasyPtr OUTL command and the SMSQ/E OUTLN command?