Hello

I've got a little bit trouble with the MUI ScrollGroup on MorphOS.

Example Program:
http://home.alb42.de/files/Leu0.02.lha

resize the Program that you have to use the scrollbars. But one cant use them, when one clicks to them, the click goes to the under laying Grid, which of course handles and "eats" the event. But the Grid cannot know if it is in the visible area or not. I'm not sure how I could do here something different, so how the error could be on my side.
This happen only on MorphOS, on AROS, Amiga MUI 3.8, it works as expected, you can move the scrollbar and the Grid underneath does not get a click.

The Grid is an self drawn Area.mui inside a Virtualgroup.mui inside the Scrollgroup.mui.


I noticed that before already with my LCL implementation where I noticed that on a multiple tabs group an element (like a button) gets a click even it's tab is not visible at the moment.

This comes down to how you handle IDCMP_MOUSEBUTTONS in MUIM_HandleEvent. Looks like you handle and eat them even when the click is outside of the displayed area of your object.

You can see it works just fine in the System Preferences if you open them on a low resolution screen. It likely works for you on MUI 3 since its routing of events is a bit different.

Hi ALB42,

thanks a lot for this new spreadsheet for MorphOS!

I have just tested Leu 0.02 Amiga68k and MorphOS version under MorphOS 3.11 and i have the same problem:

As you say, i can't select scrollbar after reduce the window size.

With the mouse wheel i can down the vertical scrollbar and when it is down i can select horizontal bar with the mouse cursor...

Maybe it may help you...

Code:

and then

Code:

to determine whether the click is meant for your object or not

thanks for your answer,

the problem I do that already, isinobject is true, I check that and exit my handler without "eating" it.

The object does not know that it's in a scrollgroup and therefore hidden by it.

If you place that carefully you can actually see how it selects the cells underneath.

How do you set up the event handler? It'd help a lot if you could share your MUIM_Setup and MUIM_HandleEvent code...

Maybe you have unconventional way of creating/adding MUI objects which breaks some flag/optimization (~I_AM_INSIDE_VIRTUAL_GROUP) used to filter out mouse clicks to objects which are in hidden area of virtual group.

sure:

I hope Github is ok, Caution Pascal

MUIM_Setup

MUIM_HANDLEEVENT

@Georg:
Interesting idea, but what that means? Its rather difficult process how the objects are created (because its recursive and deeply hidden in the pascal class system) so it exactly does it like you would write it in plain.
so its creating Area, Virtual Group, Scrollbox, Window, application.

But, as I said before I had a similar problem, when I did it forward in the LCL
so create order Application, Window, Scrollbox ... and always put with AddMember/Remmember into the parent object. (where it does not work this way because Init only, the child element gets destroyed again with the new parent attached)

[ Edited by ALB42 06.06.2019 - 11:58 ]

Try the GUIMODE flag in EHNode.ehn_Flags.
Also, calling DoSuper in HandleEvent looks incorrect. You generally don't call this at all because if the parent class needs to handle events, it installs its own handler.
Always eat click events if they're inside your own object, even if you don't do anything with them.

Quote:

_isinobject() "lies" if click happens in hidden part of half visible object inside virtual group. So for things to work the click must be filtered out elsewhere by MUI itself.

Maybe it's like this: Old MUI used to always check if filtering is required. Then someone invented MUI_EHF_GUIMODE and then changed click-kill-filtering to be done only for event handlers with MUI_EHF_GUIMODE flag. And all internal MUI classes were changed to use that flag anyway. So nothing changed for those. And for normal event handlers without MUI_EHF_GUIMODE the checks/filtering was not done anymore. And this breaks stuff which does not use or know about MUI_EHF_GUIMODE.

Thanks, it fixed it. now its working nicely.. but this is really I would never thought of, because if I would add such function I would make the flag work exactly the other way round, that it stays backward compatible.
But ok, thats none of my business, thanks very much.

Leu0.03

Hi,

It seems the new version fails to load the demo files, with an error requester saying that the spreadsheet file isn't valid. It did work on a previous version.

By the way, it would be nice if one didn't have to manually activate the string gadget to enter something in a cell.

Thanks anyway for the very promising tool.

Thanks for the notice, sorry I uploaded the wrong version ;)

now should work again.
hmm, if you double click to a cell the focus should jump into the edit field (and an enter should advance downwards)

OK, that works better.

It indeed works with double click on a cell but in a typical spreadsheet application you can just go to a cell with the cursor keys and then just start typing there.

powerpc-morphos/Leu is 68k...

polluks: fixed
now should be the right exe

Quote:

Could you be so kind to try the latest Version with that feature?
Leu0.05

Thanks

Quote:

Yes, that's perfect. I see you also added support form cursor keys to confirm input and move to the adjacent cell. Very nice improvement, so thanks a lot for that.

Another thing, is the size of the spreadsheet maxed out at either A1:S39 or alternatively the size of a loaded sheet? Any chance you could make this expand dynamically as you scroll right/down (or otherwise use a much larger hardcoded limit)?

Quote:

The problem is exactly as I described in this thread. It's just very crude, a MUI Area in a Scrollbox, that means this Area have to be as large as the largest cols/rows * width/Height of every cell
And because I draw first to a temp rastport (with own Bitmap) it needs a lot of Memory to make a lot of rows/cols. I ran already into a not enough memory situation.
The scrolling in the scrollbox also becomes slower with big images (like 2000x2000 px).
My idea was to ultimately replace that later with a own group and self manage the scrollbars, which also would make it possible to scroll together with the focus cell and make a cell wise scrolling like excel and libre office do.
The whole stuff is object oriented so it basically just mean replace a lower class layer.
I will do that eventually but not sure when ;)
Currently fiddling with TurboCalc functions (TCD loader) to convert to my own functions ;)

By the way you should not use PNG icons for OS3.
It's a bit complicated, see http://aminet.net/package/util/libs/IconLib_46.4