I see where the docs say the Container the Grid is in can be the datasource. Can it be the other way around and not introduce different behavior?
I was thinking it would keep all the parts of that interface in one object if the methods that are used on the Container could be a part of it.
Hello,
In my opinion, the data should be stored externally and displayed in the grid according to various criteria.
This can easily be achieved using an SQL database with the appropriate settings.
See example.
Thank you for the example. In this example, the GridDataSource Interface was checked in the GridManager class. Could the GridDataSource Interface have been checked in the AlbumContainer instead?
In other words, is the selection of what is checked as the GridDataSource Interface just a matter of style or could selecting a container used in the grid as “its own” DataSource have unexpected side effects, like creating problems with recursion, etc…?
My solution for accessing the tracks container is to enter the SQL ID first in the tracks array when creating the album. Only there could I get a proper return of the track number.
In TracksContainer.Buttenuebernehme.Pressed, the code var Nr as string = TracksContainer.TracksListbox.CellTextAt(0,0) then displays the entry.
In grid1.rowHeaderPressed, only the order can be determined.
I haven’t been able to get an image to be copied from Albumcontainer.albumViewer.
Hi!
Simply put: you shouldn’t use the content (ContainerControl) of a Grid as the datasource for the grid. They may get destroyed when they are out of scope for the grid (not visible), among other non-desired side-effects.
No one’s going to talk about MVC and explain why the original idea was not a good one, regardless of the Xojo specific side-effects?