I have a form which has a TDBLookupComboBox on it.
The TDBLookupComboBox is displaying a list of records from within a database table.
At the point of the forms OnShow event I would like the TDBLookupComboBox to already display one of the strings in the list.
I have done this so far...
procedure TfrmMain.FormShow(Sender: TObject);
begin
dblucbox.Text := Username;
end
Username is a string for one of the records already in the list.
At the point of compiling, I get an error saying
Cannot assign to a read only property
I'm a bit stuck with this so any help would be appreciated.
Don't try to modify the Text property, instead if you want set the TDbLookUpComboBox in a particular item you must use the the KeyValue property which will try to locate the record in the underlying TDataSet.
So you if you have Key Value of the user you can use something like this
dblucbox.KeyValue := UserId;
Otherwise you can use the Locate method of the underlying TDataSet, to find the match and the LookUp control will be refreshed automatically
You're going about this backwards. To be more precise, the DBLookupCombo is reflecting the state of the database table. So you want to be manipulating the table, not the combobox.
In other words, the OnShow event needs to open the table that's the object of the DBLookupCombo (if it's not already open) and then position the current record to be the one you want displayed as the default.
Related
So, I've been using LiveBindings between two tables at a combobox to get the Id and Description of a foreign key(with the Item.LookupData and Item.text properties) and assign the key to a field in another table with the SelectedValue propertie. This is working fine i guess but i'm using custom dbnavigator controls to make a "register form".
I'm using methods like this to make the inserts: adotablealuno.FieldValues['Nome']:=editnomeAluno.Text;
But I'cant find how to use the combobox in this way, i've already tried the ItemIndex and Selected properties, but none of this work (I'm using a Access DB btw). How can I use my foreign key in ComboBox for this?
Actually I was already stating this question and there was no good answer for a long time. I found a way out that I am currently using. At least I know that I'll get reliable data.
You need to handle OnFillingListItem event of the LinkFillControlToField link in alike way and store id number in ComboBox Items. I use Tag property for this purpose though it is not actually good.
procedure TForm1.LinkFillControlToField1FillingListItem(Sender: TObject;
const AEditor: IBindListEditorItem);
begin
(AEditor.CurrentObject as TListBoxItem).Tag :=
YourLookuptable.FieldByName('id').AsInteger;
end;
And then fetch the item id from ListBox1.Selected.Tag. The text value can be accessed via ComboBox1.Selected.Text.
Appended.
You make an alike LinkFillControlToField link.
Then you select this link and create an OnFillingListItem event handler to the link (select events tab in the Object Inspector and double click on OnFillingListItem ComboBox). The event handler (empty procedure) will appear. It will be given a name like TForm1.LinkFillControlToField1FillingListItem(... Then you write the code setting the id property to the items' Tags.
I have a form with a dbgrid and a second form with dbedits. My form with the dbgrid has a double click event(code below is the event) the dbedits on the second form has a data source that is connected to the first form's CDS and when I compile and run the program and open the form with db grid I can double click any record and it is display in the dbedits on the second form, but if I close the forms and reopen the form the only record that will display in the second form dbedits is the first record in the table. I have to open and close CDS and that is not working. what else would I need to do to correct this problem.
procedure TFRM_ADMIN.DBGrid1DblClick(Sender: TObject);
BEGIN
frm_LEADDETAILADMINLEAD := tfrm_LEADDETAILADMINLEAD.Create(FRM_ADMIN);
frm_LEADDETAILADMINLEAD.SHOW;
END;
The site will not allow me to add the dmf text. It is to large. I am using sqlconnection, sqlquery, data set provider, client data set, data source set up if this helps any.
This is a very wild quess, but I suspect the following at play:
You use the public variables for the forms that the IDE automatically has added to each unit.
You create FRM_ADMIN the way you create frm_LEADDETAILADMINLEAD, something like:
FRM_ADMIN := TFRM_ADMIN.Create(MainForm);
FRM_ADMIN.Show;
You don't close this form, but hide it (the default close action of a form).
The second time you create your second form, the designtime set DataSet property of the DataSource of your second form is automatically resolved to the ClientDataSet on the first instance of the first form.
So in the second run you are editing the record that was selected in the first run.
Solution and recommendations:
Destroy forms (set Action := caFree) in the OnClose event.
Do not use the public variables, remove them. Keep you form reference in a separate private field, unique to each instance.
Assign DataSource and/or DataSet properties at runtime explicitly.
Use DataModules.
Further reading:
Binding a second instance of a form to a second instance of a data module?
Will there be any detrimental effects if I accidentally remove something from a forms uses list which a control is referencing?
Separate DataSet instances using DataModules.
Show message when Tform2 is created?
I have a form with a query, a dataset, an editable dbgrid and an updatesql component. When I need to save the changes made in the dbgrid, I call this procedure:
procedure TEditCardDetailForm.SaveChanges;
begin
Database1.StartTransaction;
try
Query2.ApplyUpdates;
Database1.Commit;
except
Database1.Rollback;
raise;
end;
Query2.CommitUpdates;
end;
However I want the changes to be applied automatically to the database when I press Enter or go to another row after editing a cell in the dbgrid - the way it is done when I use a TTable component. Is there a way to do it?
If I understand it right (please correct me if not) you have a TQuery with CachedUpdates set to true, but want it to behave as if it would not be using cached but immediate updates. If that is the case the way you have set up your TQuery contradicts your desired behaviour. Cached updates are to be "held" on the client side until you decide to manually post them to the database by using ApplyUpdates.
In case you can set CachedUpdates to false, you only need to do following:
Link the TUpdateSQL to the TQuery via its UpdateObject property.
Write the insert, update and delete statements and assign them to the InsertSQL, ModifySQL and DeleteSQL properties of the TUpdateSQL.
I guess you already have done these two things, so putting CachedUpdates to false should do it.
You can find more information on Cached Updates for Delphi 5 here.
HTH
You have two scenarios to handle here:
save changes when changing the grid row
save changes when changing the grid column
The first one is easy to implement by calling your SaveChanges procedure in the AfterPost event of the underlying dataset (query2, a TClientDataSet?).
For the second one you only have to call query2.Post after the column has changed. This can be done in the OnDataChange event of the datasource. Make sure to check for Field <> nil and the dataset being in insert or edit mode before calling post.
I want to write an app that uses a Access database (*.mdb). I know how to connect to a mdb and how to use SQL statements. My problem is that I want to put the result of a query into a TListView.
Any info/link/book is welcomed
:)
Pull your result and then pass it to the following procedure (for example):
Query.First;
While not Query.EOF do
begin
StrObj := tStringList.create;
StrObj.Add(Query.FieldByname('id').asString);
ListView.AddItem(Query.FieldByName('Title').AsString,StrObj);
Query.Next;
end;
This will load your list view with nodes named by the fieldname title, and each node will contain a tstringlist containing whatever data you want to store for each node. Personally I would extend this and use a custom holder object rather than the tStringList, but this was just an example.
TListView is not a data-aware component, and there isn't (AFAIK) a VCL TDBListView - if you need a grid of data, you can either bind to a TDBGrid, or use a 3rd part TDBListView, which you can find with a quick google.
Using a ListView to represent a disconnected set of data is my favorite design pattern with Delphi database applications. The ListView control offers several different display formats of which vsReport is the one that looks like a table of data with rows and columns (the others are vsList, vsIcon, and vsLargeIcon).
To create "items" (which map to rows, at least when vsReport is the display style) you call AddItem() on the ListView's Items collection. AddItem will return an object of type TListItem. You can assigne a Caption to the item which becomes the description (in vsList, vsIcon, and vsLargeIcon styles) and the first column of the "table" in vsReport. The list item also has a TStringList property called SubItems. Each string added to SubItems will provide data for another column in vsReport mode (the SubItems are ignored in the other modes).
Finally, if you want to associate an integer primary key value back to your original database record you can do this using the TListItem's Data member. This is a pointer to an object associated with the item, but you can cast an integer and store it away there.
So, for instance:
DS := TSomeKindOfDataSet.Create();
try
//Set up and open DS.
while not DS.eof do begin
with ListView.Items.Add() do begin
//establish three columns for vsReport display
Caption := DS.FieldByName('DescriptiveField').AsString;
SubItems.Add(DS.FieldByname('AnotherColumn').AsString);
SubItems.Add(DS.FieldByname('YetAnotherColumn').AsString);
//Save the record's PK value
Data := Pointer(DS.FieldByname('PKColumn').AsInteger);
end;
DS.Next;
end;
finally
DS.Free;
end;
This gives you a list view containing the data from DS, along with the primary key value so that you can locate any record the user selects in the list view. DS is closed and disposed of while the user is working with the list view, so there's no ongoing demand on the database.
You can either add each record to a TListView. Just looping through the records and put the contents of the fields into the required control.
But Delphi provides data aware controls. That take care of the database connection. For most applications this is enough.
There are some implementations of VirtualTreeView that work with databases.
Here's one link, and here is VirtualTreeView web site.
Is there any specific purpose for the 'Tag' property of Delphi VCL components?
I have Googled a few examples using it as, for example, a 'color' property or using the value as a pointer address, but is it 'good practice' to use it, or is it considered 'bad practice' as it ties the program logic to the UI?
The "tag" property is there as a "cargo container" for whatever you might want to do with it.
Something it's often used for is in event handlers when you have a lot of similar components sharing one event handler. The event handler can find its caller and then query its tag value to get some more information about what it's supposed to be acting on.
EDIT:
Example: A calculator app might tag the number buttons with their respective numbers... silly and incomplete example, but you get the idea. The event handler could then pull the number to add into the display and accumulator right out of the tag instead of having to go figure out which button is meant to do what.
It is a place to add a piece of information to any component, even if you don't have the source for that component. It should be used carefully, because you can use it for only one purpose per component. For that reason Libraries should never use it.
I have some fundamental problems with the Tag property.
Well not exactly this property itself because it works as intended.
In general I consider using any universal/general/multi-purpose variables as a 'bad practice'.
They can be useful during debugging but are very harmful in production/mission critical environment.
They reduce code readability and understandability because nobody knows what a 'Tag' named attribute or property does. Of course you know why you are using this variable. But sooner or later you will forget (I know you will) and relying on this value makes anything more complicated.
This is why we should properly name every variable and property to help us understand what the code does.
Using Tag property is just a workaround/shortcut to avoid implementing understandable and well written code.
This is the PRACTICE and it is addictive.
Next time you need to store a new integer value bound to a component you will use the Tag property without considering any other way to store the desired values.
And storing a pointer in Tag property is a horrible idea: you have to cast this value every time you debug pointers.
Tell me: how many times did you find yourself in a situation where you wanted to store a new value in the Tag property but you realized this property is already used for a different purpose (if only there would be a 'Tag2' property in every component...).
As others have said, it's a place to put anything. Typically this comes in handy when associating two objects via an object reference or pointer. The tag happens to be perfectly sized to hold a pointer, so if you need to, say, keep an object tied to an item in a listbox, it becomes pretty straightforward.
Also it can be used for grouping purposes, say you'd want to access all components with a specific tag value, regardless of the component's type.
It's great! A freebie. I use it all the time to store one additional piece of information associated with the object.
Often I store a pointer to an associated data structure, or sometimes an integer which may be an index into some other array.
You can use it as a counter for times the object is accessed, or whatever.
The only downside is if your program uses lots of memory and you have millions of objects, those 4 bytes for each tag add up, especially if you're not using it. In that case, for your most prolific object type, you may want to create your own version without the tag.
You have 2 buttons on your form, on one you set the Tag = 1, and the other one Tag = 2. Now you assign the same OnClick event to both buttons and writhe the code like this:
procedure TForm28.Button1Click(Sender: TObject);
begin
case (Sender as TButton).Tag of
1: Caption := 'you pressed button 1';
2: Caption := 'you pressed button 2';
end;
end;
or more compact:
procedure TForm28.Button1Click(Sender: TObject);
begin
Caption := 'you pressed button ' + IntToStr((Sender as TButton).Tag);
end;
Basically,Tag will let you identify what control fired the event. Think if you have a form with dynamically created buttons... a list with users from the database, and on each record you put a button "Delete User". In this situation you can't create an event for each button, you will create one event that will assigned to all the buttons... and you can put in the Tag the userid for example. That way when you implement the event to handle all the buttons, you'll know what user to delete.
I Use tags all the time.
here are some examples;
a simple sample: you have a notebook (Like a pagecontroll without tabs)
so you can define buttons as tabs and write
NoteBook.ActivePage := TButton(Sender).Tag;
A more complicated sample;
an integer can hold 16 bitwise bolleans;
I can then check the senders up to 16 conditions to decide how to continue the pricedure
If (BitCheck (Bit2,TButton(sender).tag=True) And BitCheck(bit12,TButton(Sender).Tag=False) Then
Begin
end;
If (BitCheck (Bit9,TButton(sender).tag=True) Or BitCheck(bit14,TButton(Sender).Tag=True) Then
Begin
end;
You Get the idea