Forum Academy Marketplace Showcase Pricing Features

Floating group placement

I have a floating group that is a side menu on page

It is set to be at x = 0 and width is set to 235px because I want it to be only 220px but the scroll bar seems to take up 15px and if I don’t adjust the overall size of the floating group for this, the elements in my floating group are automatically resized, despite having a “fixed width” group containing all the elements.

Either way, that isn’t much of an issue as the elements on page are unaffected by this.

My problem is that I have a lot of filter choices and want to have a “second” floating group that is lined up next to the floating group that is the left side menu.

My logical thought is to set the X position of the “second” floating group to be 235 since the side menu is 235px in width.

However, the results are perplexing as the “second” floating group is nowhere near the side menu.

All that orange between the two floating groups is the color of the page for visualization of the problem.

Why is there such a huge gap?

The “second” floating group is positioned correctly if I have the X value set to 0…why would it not be displaying correctly when I change the X value…instead of being at X 235 it looks like it at X = 265

My inspector shows it as if everything is okay

Anybody ever experience something like this before and find a way to “fix it”…I don’t want to attempt to change the X value to some arbitrary number that seems to work for one screen size but changes as the page is resized because right now when I collapse the page width the “second” floating group gets pushed over toward the left of the page

There has got to be a way to get the floating group to stay in the correct X position regardless of current page width.

Responsive settings on floating groups is pretty basic, just give ability for fixed width or a max and min value.

Wow…as I was writing that post and continuously testing, the last comment about fixed width or a max and min value did one thing to help.

If I have a max width of 100 and min width of 99 on initial load of the element it is positioned correctly

The problem though is when I collapse the page width

My original page width on the editor is 1540px…you can see in the screen shots a number above the floating groups which is the current page width

When the page width is less than 1540 , the “second” floating group starts to get pushed to the left and covers the side menu floating group

40%20PM

Obviously not a good thing.

The only thing I can think to do is to set the “second” floating group to have a width of 435px and an X value of 0

The basic problem with this is that the user will lose access to the side menu floating group because the “second” floating group is basically “covering” the side menu.

So what I did was set the “second” floating group to “send to back” and this now allows the user to access the side menu while the “second” floating group is visible.

23%20PM
Hopefully this “real time” problem solving helps somebody who stumbles into the same problem I did.

This is extremely disappointing.

After testing and retesting and having everything working as hoped for now the "second’ floating group is on top of the floating side menu and no matter how many times I send the “second” floating to “go to back” and call the side menu floating group to “bring to front” the problem persists and the “second” floating group is covering the side menu making it so users can not interact with it or see it.

Does anybody know of a way to make sure the floating groups react to the “bring to front” and “send to back” settings.

The worst part about this is that I never changed the settings after I got it to work yesterday. It was working fine all day, and then randomly stopped working just minutes ago with no return to normal.

Please file a bug report if you can verify it. I’ve had the same report pending for 40 days now. @bubble come on…

@duke.severn

I sent a bug report…however with my hard headedness I had to dive deeper into the problem and figure it out for myself and think I have found the root cause of the problem.

It seems it has to do with the “replace” feature on the element. Originally my side menu was a group and I replaced it with a floating group.

I had played around with using javascript to set a Z-index and had the same issue with non-performing floating groups that I created by “replacing” groups with the floating groups. They did not respond to the JS as the groups had. So, I created “fresh” floating groups and using the same JS they responded the same way the groups did.

This app has the floating groups working appropriately and layering them correctly.

edit

As a side note…on the app that I had the problem, which was fully built and way too detailed to change all the settings, and therefore deleting the side menu was not an option to rebuild with an element that was originally a floating group, I set up a Javascript to set the Z-index of the “fly out menu” that was covering the side menu.

03%20PM

Adding a 100ms pause was essential to getting this to work, as without the pause it didn’t set the Z-index on the “flyout menu” which is an element id of “sidemenu2”

Now I don’t need to spend hours reconfiguring the entire page to get it back to functioning correctly.

3 Likes