I'm using Delphi 6, and I want a database bound list box with multiselect. I found three types of List boxes: TListBox, TDBListBox and TDBLookupListBox.
As far as I can understand, TListbox is not bound to database. TDBListBox and TDBLookupListBox can't be multiselected.
Is there a way to get a multiselect listbox binded to database?
The problem with databinding components is that they rely on a datasource and a datasource has only a single cursor. That is probably the reason why.
By the way, do you need to change the data? Else you could fill a normal listbox from a dataset. Or even use an invisible data listbox and copy the contents to a normal listbox.
Not as far as I know.
The standard is that you offer with the list a bunch of values in which 1 represents the current record.
Unless you have a multivalued field (against best practices) I can't see how you could multiselect...
Or what you might want is actually a sub-table?
DevExpress TcxDBListBox supports multiselect. I use their multiselect drop down check box bound to a database, it's sweet.
The components have methods you can implement to convert to and from your list; EditValueToStates and StatesToEditValue. While the data I store is not normalized (I store a semi-colon delimited list of version numbers), I created a full text search index on the field, with a semi-colon as a delimiter, and now I can still perform optimized searches on that field.
You could create your own custom listbox component that descends from TCustomListBox and add a Datasource property for your list, and another property such as TStrings to be used as a container to hold selected values. You could then post changes to your database using a button click.
If you fiddle with some of the options of a TDBGrid and restrict the columns it displays, you can make something that looks a whole lot like a listbox. Try setting the Options property to [dgTitles,dgTabs,dgRowSelect,dgAlwaysShowSelection,dgCancelOnExit,dgMultiSelect] and work from there.
In a TDbLookupListBox you have the option to bind two different things to data; first you can bind the list to a dataset (ListSource/ListField/KeyField), second you can bind the selected item to a field in another dataset (DataSource, DataField). There is nothing conceptually wrong with wanting to bind the list of items to a dataset, and then manually manage multiple selections, however I don't think it is possible with the current implementation without subclassing and enabling the required control styles.
Based on your comment to François, I would use a normal TListbox and write code to insert all distinct values into the list, and then handle the multi-select values yourself. Jeremy's solution also works, and the DevExpress Express Quantum Grid has a nice filter system which might even save you some other programming.
Related
I have a quite long list of (string) values in a TCheckListBox.
I want to allow the user to do some simple filtering of this list by checking some external CheckBoxes, indicating the filters.
In order to save some coding, I'm looking for a solution that simply hides filtered items in the TCheckListBox.
Question is, is this even possible?
I have found that there are ways to set individual items 'state' and enabled properties, but can't find a 'visible' property.
You cannot "hide" list box items. You must physically remove them from the list. So during your filtering process, you will have to re-populate the list box to display only the relevant items that match the current filter.
Otherwise, switch to something like a Virtual TreeView instead (despite its name, it can also be used to simulate lists and grids as well as trees). Its nodes can be hidden without actually removing them.
D5, ZEOS 6.6, SQLite.
I have srcAccount.AutoEdit = False;
I have All Edit functions set to False in the TDBGrid Options. Only options are set to true are Indicator, grind lines and Titles.
I have a form with a few TDBEdits and a TDBGrid on it showing all the current accounts.
When the user clicks the "New" button for a new account I have
dbedAcct.SetFocus;
tblAccounts.Insert;
If, after clicking the New button, the user wants to scroll to check Account names OR happens to click in the grid, it saves the new data and drops out of Insert mode.
How can I stop this happening? I need for them to be able to check account names.
Or, is this a bug with D5? If so, how do I work around it?
I also tried using SMDBGrid and it does exactly the same thing.
http://www.scalabium.com/smdbgrid.htm
I need for them to be able to check account names.
You can't do that using the same grid + dataset if you're allowing the user to do data entry to the grid. You are creating this problem for yourself by trying to use the grid for data entry and look-up at the same time. A simple solution is to use the grid for look-up and have a separate form (or panel on the same form as the grid) for doing the inserts, and these need to be connected to different dataset instances.
The thing is, you can't scroll around a dataset (as you need to do you look up other records) while it's in the middle of inserting a record. The dsBrowse state needed for a dataset to allow scrolling around and the dsInsert state needed to insert are mutually exclusive. Attempting to scroll the dataset will automatically post the pending insert, as you've found.
So, you actually need two dataset instances, one for lookup and one for inserts. If you use two client-side ClientDataSet instances, it can be quite straightforward because of the ease with which you can copy the data from one to the other using the CDS's Data property (cdsLookup.Data := cdsLive.Data), so making a local copy for look-up is trivial. Or, if you prefer you can use a cloned cursor - see http://edn.embarcadero.com/article/29416
I want to add some data in grid to show user.
I want to use TDBGrid
How do I add any row to grid without a database?
Thank you
A TDBGrid reflects the data in an underlying dataset (query, clientdataset etc). To have new or changed data appear, update the data in the dataset (and/or maybe refresh it).
If you do not use an external database, your are still able to use e.g. a TClientDataSet and store its data to file (proprietary format or XML, depending on your Delphi version - see its documentation). Given the flexibility of using datasets (e.g. editing the data), I recommend this.
Alternatively, use a TstringGrid and store your data in any (other) way you want.
[It also depends on what else you want to do with the data once it's presented in the grid. If you want the user to be able to edit it, TClientDataSet is the way to go.]
In the grid's properties I have selected one column to sort records (sort order) ASC.Works OK.However, when I use the cxDBNavigator and try and go to the last record, it does not go to the last record in the grid but the last record entered in the database. What is the use of using the sorting properties of the grid if the dbnavigator does not follow? Is there a way to correct this (apart from sorting records in code) ?
CxDBNavigator is navigating in the dataset, not in the grid.
Since the data in the cxGridDBTableView or cxGridDBBandedTableView is sorted in the grid you will have to take cxNavigator instead of cxDBNavigator and bind either the view or the grid to the property Control of the cxNavigator.
Is it possible to translate the display name of choice list items defined for LightSwitch entity properties?
I would like to be able to show different users translated display names in their language when they are viewing the SAME record, and also show translated names in the autocomplete combo box when they are editing a record.
Not really, no. The values are stored in the LSML file & aren't able to be modified at runtime. If you need to translate the values, then you'll need to use a lookup table (possibly by using a custom RIA service) instead of a Choice List.
The advantage of a Choice List is that it's very quick & easy to set one up.
The down side of a Choice List is the lack of flexibility, or even reusability (you have to define the values for the list every time you want to use it somewhere).