Need a grid of buttons that can have text/graphics in them

[alank2 5]

I am pretty new to FireMonkey.  What I need is a grid of X wide Y tall buttons that can be clicked.  No scrolling.  Each button needs a couple text labels and a graphic.  I need to build the grid at design time.

 

I don't mind building the controls dynamically if that is easier.  My original plan was to use a TSpeedButton and put TLabels and an TImage on it.  If I hover over a TLabel, it activates the button, and clicking activates the buttons onclick event not the label's.  TImage does not work the same way however - can it be made to allow hovering to pass through to the button underneath it?

 

Or is there a better way to go about this?

[corneliusdavid 142]

For a "grid" of buttons, you don't need to use a grid control--the first thing I thought you meant when I was reading this. Instead just place the buttons in a grid-like manner on a form or panel. I would highly recommend using a FlowLayout to provide automatic arrangement of the buttons to accommodate both landscape and portrait views of the app (if you're aiming to put this on small devices). Watch this Embarcadero video that demonstrates the concept.

Edited January 13, 2022 by corneliusdavid

[corneliusdavid 142]

Whether to build the controls dynamically depends on your project--if you have a lot of buttons or want them added dynamically based on configuration or options or something, then that's very doable. It's a little easier to see how everything will fit and look if you do it at design-time, though.

 

For activating when you hover over a button, use the MouseEnter and MouseLeave events.

[qubits 20]

Change the HitTest of the timage to false, click should flow down.  there's also an AutoCapture property in timage, might get you're hovering going too

[David Schwartz 413]

I'm doing something similar right now. I found a TjanRoundedButton component somewhere and am using that. I lay them out on a panel in an x-by-y matrix. I ended up subclassing it to add some additional things I needed and I use instances of my own class on the panel. The original is fairly basic but easy to extend. I may ultimately switch to a grid, but to my eye, this approach looks better because it offers isolation between the "cells" whereas a grid jams them all together.

 

In my case, I must create them at run-time because the number of rows and cols is data-driven. I found it easier to just lay them down algorithmically rather than use any of the fancy flowgrid/panel/etc options. 

 

I end up with one or more tabsheets, based on how many data sets are present. Then I add a TPanel on the tabsheet (which is probably redundant), and then add the buttons in a grid layout.

 

Honestly, while prototyping I put them all down at design time, and it slowed the IDE down quite a bit. I didn't need them at design time, so doing it at run-time keeps the IDE from slowing down.

 

(I've got this other thing that's a 9x9 array of radio buttons organized in columns using 9 panels, and it slows down the IDE as well. But they're static and it helps to have them at design time.)

 

 

Edited January 13, 2022 by David Schwartz

[corneliusdavid 142]

2 minutes ago, David Schwartz said:

I found it easier to just lay them down algorithmically rather than use any of the fancy flowgrid/panel/etc options. 

I'm going to take a guess that it's easier because you're used to writing the code to do that. I'll bet, with a bit of research and experimentation, you could save yourself a lot of code using a "fancy flowgrid/panel/etc". These components make laying things out not only very quick and easy but also work with fluid form sizes (like mobile devices) a breeze when things change at runtime. Of course, desktop apps often have a rigid layout so it's not critical, but since this discussion is based on FireMonkey, we can't assume it isn't mobile.

[alank2 5]

Thanks everyone; HitTest property fixed the issue for me!

[David Schwartz 413]

3 hours ago, corneliusdavid said:

I'm going to take a guess that it's easier because you're used to writing the code to do that. I'll bet, with a bit of research and experimentation, you could save yourself a lot of code using a "fancy flowgrid/panel/etc". These components make laying things out not only very quick and easy but also work with fluid form sizes (like mobile devices) a breeze when things change at runtime. Of course, desktop apps often have a rigid layout so it's not critical, but since this discussion is based on FireMonkey, we can't assume it isn't mobile.

Nope. I spent a few hours trying to get those flow-things to work for my needs. They do something similar to word-wrapping, which does not preserve an X/Y grid layout which is what I was after. I could have used something like a big sheet of paper that slides around under a viewport and lets you shrink or expand the scale of the paper, but that's not what these things do. 

 

They do what they do. It's just not what I wanted.

[qubits 20]

Hi Dave.

 

Some crazy requirements, but maybe you already have your answer.

Maybe make the whole mess one image, track x,y on clicks.

You could even work out a pinching and scrolling I bet.

Resource consumption goes down to nada.

Build your image just like your building your screen.

You could have thousands of what looks like individual controls but really aren't.