Third party grid controls for Access?

[SeanR01]

Hi,

I'm looking for a fairly basic grid view control that will work in Access 2000/2003 on XP. Minimally, it would work like a cross between an Access listbox and a datasheet subform. Required features are:
[ul]
[li]ability to double-click or otherwise select and launch a row item or multiple items into another form -- easy selection with checkboxes or similar would be good[/li][/ul][ul]
[li] ability to edit items directly with combo boxes in the grid using table lookups in the db, and saving back to the data source table[/li]
[li]ability to also control access to which columns can be edited[/li]
[/ul][ul]
[li]ability for the user to change column widths, and possibly add and subtract columns[/li]
[li]ability to at least sort columns, or group/outline tree structure[/li]
[/ul][ul]
[li]fairly easy to program and populate with Access table data[/li]
[/ul]
More elaborate features:
[ul]
[li]tree views might be a useful feature if not too complex, allowing to group work orders by supplier or similar -- ideally I would like 'dynamic grouping' as well, i.e. you can change the view to group and outline by any desired column, e.g. supplier, location, or equipment type.[/li]
[/ul]
The problem with built-in Access approaches is that a listbox lets you double-click to launch and multi-select, but not sort or change columns. A datasheet subform lets you do a lot with columns, but not easily double-click to launch, and you can't change columns or order. A continuous subform can be set up to look like a grid, but obviously also won't let you change column widths interactively or do sorts easily without a lot of coding.

I'm trying to port an app (or actually half an ERP) originally written in Delphi that has a reasonaby good data grid control which does some of the things above, except for inline editing. The Access controls are a fair bit more limited than this when you try to emulate it. I've found a couple of 3rd party grid controls online with VBA/Access support, but there's a bewildering array of meta-sites and forums and products out there, and you find the products often only work in .NET etc. Also, a lot of them seem to have a huge amount of drilldown functionality which I probably don't need -- but then, who knows, it might be handy for end user analysis purposes that I currently do for them with queries and so on. They also seem to have massive support for images, different presentation layouts and widgets and so on, which I also probably don't need for straight data. I've downloaded something called TList for the moment, but does anyone have a good birds-eye view of what is available out there in this type of combination listview/gridview control?

Thanks,
Sean

 

[JoeAtWork]

I believe all your requirements, except the treeview, can be done with a datasheet.

I get the feeling you are looking for something that can do everything but without requiring you to do any coding. The fact is that if you want customized behaviour you will have to write code. This is true whether using a third-party control or using the built-in Access controls.

 

[SeanR01]

> I believe all your requirements, except the treeview, can be done with a datasheet.
>
> I get the feeling you are looking for something that can do everything but without requiring you to do any coding. The fact is that if you want customized behaviour you will have to write code. This is true whether using a third-party control or using the built-in Access controls.

Yes, I would like something that did everything I want without much coding, that's the dream isn't it?

The problem with a datasheet is in launching -- I don't believe it's possible to launch a single record from a datasheet with a double-click, the double-click event is tied to the form level. It's possible with code perhaps to identify the current selected record at the time of the form double-click and use a unique indentifier in the record to launch it, but it's not intuitive for end users to operate like this -- and the row selectors on a datasheet are a poor way of selecting a row for launching.

If it's possible to do this elegantly, I don't mind writing the code to do it -- although the more coding you have to do, the messier it gets, the more error-prone it can be, and you start hitting other limits of Access forms as you go.

But yes, column manipulation is possible, combo boxes are straightforward, and so on. Not sure if it's possible or easy to add check boxes for individual row selection though without losing updateability of the source data.

I'm considering TList at this stage only because it's been the easiest to locate and download that works with Access VBA, and does most or all of the things I want -- although columns look a bit suspiciously fixed...

 

[ZmrAbdulla]

Did you read the reply at

http://www.tek-tips.com/viewthread.cfm?qid=1482094

________________________________________________________
Zameer Abdulla
Help to find Missing people

 

[SeanR01]

Yes, thanks Zmr, I trust the VB6 control will also work OK in VBA? I've installed it and had a quick look, looks like it might go...

It looks like it has reasonable capability... then the only problem is programmer bugs in the control

 

[ZmrAbdulla]

I had tried it in the past. Not in deep level. I feel it is fine.

________________________________________________________
Zameer Abdulla
Help to find Missing people

 

[JoeAtWork]

The problem with a datasheet is in launching -- I don't believe it's possible to launch a single record from a datasheet with a double-click, the double-click event is tied to the form level. It's possible with code perhaps to identify the current selected record at the time of the form double-click and use a unique indentifier in the record to launch it, but it's not intuitive for end users to operate like this -- and the row selectors on a datasheet are a poor way of selecting a row for launching.

Of course you can open a second form from the double-click event of the main form. The main form always knows what the current record is, so you just pass it the ID field as an opening parameter or as a filter.
If you think something is unintuitive, then just add your own controls and put code behind them. E.g. place a button that opens the detail form, or whatever.
I believe your requirements, except for the treeview, can be achieved with very little code (a few lines) using everything built-in with Access.
I have usually had trouble with third party controls, I tend to stick with the default Access set as being the more reliable choice.

 

[SeanR01]

Joe,

I take your point about reliability problems with inherited controls that aren't rigorously tested. I'll think about it, but what about the following instances?

Of course you can open a second form from the double-click event of the main form. The main form always knows what the current record is, so you just pass it the ID field as an opening parameter or as a filter.

OK, what if our user wants to select the 1st, 3rd and 5th rows for opening? I don't think that's going to be possible with a datasheet -- it would be nice to have a (non-contiguous) multi-select in the interface, which implies a checkbox capability or similar. The idea is that users will be returning rows of data after a search, then choosing to open certain items, 1, some or all. Is it possible to set up a query in a datasheet with a boolean dummy field as an expression, will it display as a checkbox, and will the underlying query remain updateable inline?

If you think something is unintuitive, then just add your own controls and put code behind them. E.g. place a button that opens the detail form, or whatever.

This is OK except in the case of multi-select, I fear...