When creating TDBGrid components dynamically at runtime, i can't forbid user to edit values in cells. This is how I am trying to accomplish this type of behaviour:
TDBGrid *DbGrid = new TDBGrid(Owner);
DbGrid->Options = DbGrid->Options >> dgEditing;
When disabling dgEditing in form designer all is functioning correctly. I can't find the difference between these two cases. What should I do to disable edit of DBGrid cells?
The trick is to do this in following way:
DbGrid->Options = TDBGridOptions(DbGrid->Options) >> dgEditing
but I do not know what is the difference.
I have the same problem with the Seattle version of C++Builder in that I am unable to programmatically change whether the DbGrid allows or disallows editing. The DbGrid->Options values CAN be changed without requiring the TDBGridOptions() cast but the DbGrid does not follow what the DbGrid->Options are set to. If they are set in the object inspector for dgEditing enabled, then the DbGrid always allows editing no matter what the state of DbGrid->Options.dgEditing is and if in the object inspector dgEditing is disabled then the DbGrid never allows editing. It at first APPEARS to work (i.e. the highliting of rows vs cells changes). I have tested this using both DbGrid->Options.ToInt() and DbGrid->Options.Contains(dgEditing) to ensure I'm not stumbling over myself.
I finally found a way to make it work.
If you set the dgEditing to true (for the Options of the DBGrid in the Object Inspector), this will let the user edit at any time. Then, set DBGrid->ReadOnly=false when the user should not be allowed to edit.
I did not have any luck trying to set the individual DBGrid->Columns->Items[ii]->ReadOnly=false. The program did not prevent me from doing that, but it did ignore whatever I had in it.
I wrote a special small test program with minimum components and was able to get good results just by setting the dgEditing to true in the object inspector and then changed dgEditing to false when I wanted to prevent the user from editing, but when I put it into my full program, something prevented the DBGrid from working.
The DBGrid->ReadOnly may be a work-around for someone else also.
Related
I had created a simple program which includes many checkboxes and TComboEdit. When an certain checkbox is checked, then an editbox becomes enabled. Some checkbox is checked by default. My problem is when I run the program the unchecked component's edit box are visible too, which should be disabled as the checkbox is not checked at all. But when I check them and uncheck again the edit box disables which it should be. So how to update component's status at form create ? Or any other good way to do it.
so sorry for the grammar mistakes.
Either set the visible property of the edit fields to false in the designer, or do as David Heffernan suggests: Write an OnCreate handler, where you do that in code.
I have a weird situation here. The ParentFont property of newly-added components keeps changing to FALSE, within the IDE.
I can demonstrate it as follows:
File|New VCL Forms Application. No need to save anything.
Add 3 tLabels to the new empty form.
In turn, look at each one in the Object Inspector. The ParentFont is set to FALSE - it should be true.
Change each of the labels to ParentFont = TRUE.
Change the font size of the form, several times, and confirm that the labels change as expected.
Select one label, check its ParentFont in the Object Inspector. It's FALSE again!
Change the font size of the form again, and note that the last-inspected label doesn't change.
To me this is consistent with the label's font somehow being changed upon being selected in the IDE, however I can not detect this.
Does anyone have an idea what might be broken? And/or what I can do about it?
=========== [EDIT] ==============
Well, I have uninstalled and done a clean install of Delphi, with no 3rd party components. The problem is still evident!
Here's a video to demonstrate:
http://topshare.com.au/DelphiParentfontProblemDemo.avi
Turns out it's a known problem with XE5:
https://forums.embarcadero.com/thread.jspa?messageID=716297#716297
I seem to have a mental block with this one.
I need to save recent changes to a Record. I am doing it OK with buttons for "New" "Edit" "Post" "Next" etc but when a user double-clicks a DBGrid, it is now too late to make changes as the DBGrid selection has moved the database cursor to the selected record.
I can't use AutoUpdate as the data that may have been changed is not something the user would have directly entered, it is a value that is changing all the time.
I'll try to describe it better: While the user is reading a Test-page, a timer is counting down or up. When they click the "Next" or "Prior" buttons I can save the timer setting. But, if they Double-Click the DBGrid I have no way of first changing the current Record before the selection moves to the clicked-Record.
I tried using the
Procedure TForm1.tblTestOnBeforeScroll(...
begin
tblTest.Edit;
tblTest.FieldByName('TimerCt').AsInteger:=ClockCtr;
tblTest.Post;
end;
But, that crashed the database, not surprisingly, but I thought I would give it a try before asking here.
How do I deal with the current record? I do not want to disallow the double-click if possible as it seems nice and intuitive for the user.
I'm afraid that what you do on DBGrid is a wrong in concept action.
Key point is DBGrid is a data aware control. So everything you do on it must based on it's datasource then it's dataset.
There is a DblClick event on TDBgrid. But still you have to check it's dataset to see what record is active.
The code you shown above clearly lead you to an endless loop.
When you doing a scroll, the dbgrid will call OnBeforeScroll event, moving the active record
and call OnAfterScroll. Your OnBeforeScroll code does an data update. Then dbgrid abort its operation cause of data change. Then after data update, it try to scroll again, and the data change happen again. Endless loop happen here.
best regard
Apologies in advance if I'm misunderstanding you, but it seems to me that either the premise of your question is wrong or there is something relevant you haven't told us about what you're doing. Please try the following:
If you don't have one already, please temporarily add a DBNavigator to your form and connect it to the same DataSource as your DBGrid. The point of doing this is so that you can more clearly see what's going on.
Then, in your DBGrid's Options, set dgEditing to True.
Finally, comment out or disable your BeforeScroll handler, save and run your program.
Now, click once in some cell in your DBGrid that contains a value which it's ok to change. Click it a second time so that it selects the value in the cell rather than the cell per se.
Make some change to the cell value, but do nothing else for the time being. You should notice that a) the current record indicator of the DBGrid has changed from a black triangle to an I-Beam graphic, like ][ and b) that the tick and cross buttons of the DBNavigator are now enabled.
Now, without doing anything else on the form, click in another row of the DBGrid. You should find that a) the change to what was the current record in step 5 has been saved and b) the current row indicator reverts to the black triangle and the DBNav's tick and cross buttons are disabled.
(If you don't get the behaviour I've just described, create a minimal new project and try that instead, as some other change you've made in your existing project may be interfering with it).
What I've described in 5 & 6 is the default behaviour of a DBGrid and insofar as I understand your q, that seems to be the behaviour you're trying to achieve. If that's not the behaviour you want, please explain exactly how what you do want differs. It's not clear to me where the user double-clicking on the grid comes into your q, except that that action may move the dataset's cursor (if the dbl-click is on a different row than the current one), but as the default DBGrid behaviour will save changes to the current row before it moves the dataset's cursor, it will do what you seem to want automatically.
Btw, what "AutoUpdate" do you mean? Did you mean TDataSource's AutoEdit property?
I've customised the style of a Firmeonkey list box item in such a way that now it can consist of 4 TLables in it. Each of the lable has Alignment as alNone.
I'm setting position of each of them in my code whenever i need to add any item. I've observed that when my list has scroll bar and if first component is not visible (i.e. i've scrolled down enough) at that time if i re-add all the items again in list box, then the position of TLabels in first items (or items which are not shown) get distorted.
For setting positions I am using below code :
(tmpListBoxItem.FindStyleResource('txtCol2') As TLabel).Position.X :=
(tmpListBoxItem.FindStyleResource('txtCol2') As TLabel).Position.X + (tmpListBoxItem.FindStyleResource('txtCol2') As TLabel).Width;
Any suggesstions, how can i overcome this issue.
Regards,
Padam Jain
Firemonkey styles are repeatedly 'applied' and 'freed' as components appear and disappear from screen.
It is not enough to simply set properties of style objects once and expect those values to be remembered. What you need to do is either listen to the OnApplyStyleLookup event or override the ApplyStyle method of a custom component and use the same you have above to set the properties again.
This means you'll need somewhere to store the values you are going to set.
I would suggest for your situation that you subclass TListBoxItem so you can add suitable properties or fields and put your code in ApplyStyle.
If I set mycoolbar.fixedorder to true,only the grip on the first band will be hidden.
Well,If you use Delphi 7 to create an VCL Forms application,then put a coolbar on it and create 3 coolbans to hold other controls,only the grip and the top coolbands can be hidden by setting mycoolbar.fixedorder:=true.
I've uploaded a picture to make things clear.
You probably got a FixedOrder property wrong. The fixed property does not allow bands to be rearranged if set to True.
Setting up property of CoolBar to True keep user from changing the bands order at runtime, but the user can still move and resize the bands. I can actually give you advice what you can do, but the actual solution for your problem, well, you will have to wait for another answer.
My advice is to use three CoolBars in a row and setting their "FixedOrder" property to True and BandBorderStyle to bsNone. That way the grip will be hidden on all of them.
About the property, it's not a bug of IDE, it is the actual preference of the property.