TComboBox appears to be slightly broken
Ted Byers
form with a number of controls including comboboxes, and a TStringGrid to
display data that has already been entered. Selection of a row in the grid
is supposed to populate the controls in the data entry portion using the
data in the selected row. In almost all cases, this works fine.
In one form, I set up the combobox with the style 'csDropDownList' to
restrict the data entered to the options represented in the list. Doing so
works fine, with regard to restricting the data accepted to the options in
the list, but it breaks the required interaction between the data entry
portion of the form and the TStringGrid.
I have tried the following:
1)
....
ParentCMBO->Text = ReactionDataSG->Cells[1][ARow].c_str();
2)
...
AnsiString tmp = ReactionDataSG->Cells[1][ARow].c_str();
int imax = ParentCMBO->Items->Count;
int i;
for ( i = 0 ; i < imax ; i++ ) {
if ( tmp == ParentCMBO->Items->Strings[i] ) {
ParentCMBO->ItemIndex = i;
break;
};
};
3)
ParentCMBO->ItemIndex = 1;
In all three cases, the following statement, as well as what I see in the
form, shows that wheter I try to set ParentCMBO->Text or
ParentCMBO->ItemIndex, the setting is not accpeted.
ShowMessage(ParentCMBO->Text);
I can understand failure of trial #1, because that precludes
programmatically setting the text value to something not in the list, but it
is an annoying limitation to what a developer can do. Presumably if a
developer wishes to programmatically set the text to something not in the
list, while restricting user defined data to items in the list, he knows
what he is doing. I do not understand why trials #2 and #3 failed since
they would be simply selecting items from the list.
Unless there is a simple fix for this, I expect that the only work around is
to set the style of the combobox to 'csDropDown' and then move code like
that in trial #2 (replacing the setting of ParentCMBO->ItemIndex and the
break by return, and adding code after the loop to show a messagebox
indicating the error and forcing the combobox to keep focus until acceptable
data is entered) to the exit event of the combobox to handle rejecting data
that is not found in the list.
Any ideas?
Cheers
Ted
R.E. Byers
rtb...@bconnex.net
Mark Cashman (TeamB)
I haven't had a chance to test this with your type of combo, but the way
I usually set a combo from something else is:
ComboBox->ItemIndex = ComboBox->Items->IndexOf(SourceAnsiString);
This cleanly yields -1 when the item isn't found. Note that you don't
need all that c_str() stuff, either.
I'd also recommend
ComboBox->Update();
afterward to ensure the imagery gets updated.
Please indicate the version of C++Builder that you are using if you have
additional questions on this topic.
------
Mark Cashman, TeamB C++ Builder
http://www.temporaldoorway.com/programming/index.htm
C++ Builder, JBuilder programming information
Home of The C++ Builder Programmer's Webring - Join us!
------
Ted Byers
Following seeing your reply, I tried the following.
...
AnsiString tmp = ReactionDataSG->Cells[1][ARow];
ShowMessage(tmp);
ParentCMBO->ItemIndex = ParentCMBO->Items->IndexOf(tmp);
ParentCMBO->Update();
...
and
...
ParentCMBO->Text = ReactionDataSG->Cells[1][ARow];
...
In both cases, I had previously changed the style of the combobox to
csDropDown. With this style only does the second trial work. In no case
that I tried did the first work. The ShowMesage call showed me that tmp had
received the correct value, and since it was obtained from the combobox list
in the first place, we know that IndexOf() OUGHT to have returned someting
other than -1 (but silly me, I didn't check that). However, even with
thestyle set to csDropDown, the combobox text entry is left blank, so
ParentCMBO->Text is NOT getting the correct value, or so it seems (if it is
getting the right value, I don't know why it would not display it). What
other magic is necessary to get the IndexOf() approach to work? I am
interested since it would make my code a little cleaner (although I'd wager
that the function itself uses a loop like I had, or, if the items are stored
in a binary tree, a recursive seek function - so there is probably little
difference in performance between writing the loop myself and relying on a
built in function).
BTW: the c_str() stuff is a habit I have developed recently because I
routinely use STL with strings, and to convert between the STL strings (to
exploit support built into STL containers for them) and the AnsiStrings VCL
components use, so I use:
string sSTL;
AnsiString sAS;
...
sSTL = sAS.c_str();
...
sAS = sSTL.c_str()
..
There is no VCL counterpart to the set and map containers is there? I find
these, along with there mset and mmap counterparts, especially useful with
string and less<string>. I don't think I am smart enough to produce better
code than that which already exists in STL.
Using the unnecessary call to c_str() doesn't break anything as far as I
know, but it saves a little aggravation when it is necessary to mix STL with
VCL, and the overhead is hardly noticable since most of this conversion is
contained within the user interface where the program is usually waiting on
the user for input.
I am using BCB v 5 Pro.
Mark Cashman (TeamB) <mcas...@temporaldoorway.com> wrote in message
news:395A3626...@temporaldoorway.com...
Ted Byers
Ted Byers <rtb...@bconnex.net> wrote in message news:395a4aa2@dnews...
> Hi Mark,
>
> Following seeing your reply, I tried the following.
>
> ...
> AnsiString tmp = ReactionDataSG->Cells[1][ARow];
> ShowMessage(tmp);
> ParentCMBO->ItemIndex = ParentCMBO->Items->IndexOf(tmp);
> ParentCMBO->Update();
> ...
ItemIndex has been set to -1.
tmp = ParentCMBO->ItemIndex;
ShowMessage(tmp);
Since the value in tmp came from the list in the first place, why would
IndexOf() return -1? Is it possible that either TComboBox or TStringGrid is
adding an invisible character to the end of the string when it receives it?
But I do not see why it would, and on other forms, I am passing data among
STL containers, TEdit controls TStringGrids and TComboBoxes without
difficulty, so I do not underdstand why this particular form is so
troublesome. In most respects it is simpler than any of the other forms,
except that the text allowed in the comboboxes ought to be restricted to the
contents of the associated list.
Any ideas?
Cheers
Ted
Timothy H. Buchman
enter text...". I think that's why *you* can't, in effect, "enter"
text by assignment to the Text property. The only way you can get
that box (the "edit box") to show something is to, as MC said, set the
ItemIndex, which fills in the edit box *for you* after selection of
the existing item takes place.
-------
Timothy H. Buchman
========================================
City Center Theater, New York NY
mailto:tbuc...@citycenter.org
Please treat this signature information as confidential.
========================================
Search .borland message archive on http://www.mers.com/searchsite.html
Ted Byers <rtb...@bconnex.net> wrote in message
news:395a4aa2@dnews...
> Hi Mark,
>
> Following seeing your reply, I tried the following.
Ted Byers
The thing is, when I have style csDropDown, I CAN set the text by assigning
to the text property. I have not had any luck, however, setting ItemIndex.
But I have a hunch that it may have something to do with TComboBox losing
the list data on exit from the combobox. I find I have to set that data in
the onEntry event in order for the combobox to funxtion. I do not know why
it doesn't allow me to just set it when the form is created, and keep it
until the form closes.
Cheers,
Ted
Ted Byers
I have a hunch as to the source of the problem, but I am clueless as to the
fix.
I find that in order for the comboboxes to work, I have to have code like
the following in the onEntry event of the combobox.
{
TMyElementEntryForm* boss;
boss = static_cast<TMyElementEntryForm*>(Owner);
if (!boss) exit(EXIT_FAILURE);
parents = new TStringList;
refs = boss->getReferences();
elements = boss->getElements();
element_map_type::iterator IT = elements->begin();
while (IT != elements->end()) {
if ( (*IT).second.getRadioactive() )
parents->Add((*IT).second.getName().c_str());
IT++;
};
ParentCMBO->Items = parents;
}
'refs' and 'elements' are STL maps.
I added the following code for diagnostic purposes.
...
AnsiString tmp = ReactionDataSG->Cells[1][ARow];
AnsiString nTMP;
int i,imax;
imax = ParentCMBO->Items->Count;
for ( i = 0 ; i < imax ; i++ ) {
ShowMessage(ParentCMBO->Items->Strings[i]);
if (tmp == ParentCMBO->Items->Strings[i]) {
nTMP = i;
break;
};
};
if (nTMP.Length() > 0) {
tmp += " was found at position ";
tmp += nTMP;
} else {
tmp += " was not found";
};
ShowMessage(tmp);
...
The above code, placed in the selectCell function, shows none of the items
that ought to be in the list when a row is selected by the user. Curiously,
when the Add button is clicked from the entry portion of the form, all of
the items that ought to be in the list are displayed. I do not know when or
why the combobox loses the list of strings it ought to contain, but the list
is empty unless I put the above code in the onEntry event of the combobox,
and it clearly is empty when the stringgrid receives the focus.
The final ShowMessage() tells me that the string was NOT found, even though
I know it ought to be in the list of items in the combobox, and even though
it appears in the list when the combobox receives the focus. That would
explain why it IndexOf() returns -1 when, given the test data, it ought to
return 0 or 1. It would seem that setting ItemIndex will only work if
somehow the combobox can be forced to retain the data given to it until it
is told to get rid of it.
Any ideas? I suspect I could repopulate the list of strings in the combobox
in the select cll event of the grid, but if the list of items gets big, that
may introduce a detectable performance hit and it seems to me to be a little
inefficient (as is the necessity of doing so in the onEntry event of the
combobox - but I haven't found a work-around for that yet).
Any ideas?
Cheers,
Mark Cashman (TeamB)
The idea of items vanishing is perhaps significant of a problem in your
code. It is not normal TComboBox behavior.
Indeed, here is a test harness I wrote to simulate this. The following
are the controls, copy and paste them from here onto a new application
form and the controls will appear...
object ListBox1: TListBox
Left = 0
Top = 0
Width = 297
Height = 217
Align = alLeft
ItemHeight = 16
Items.Strings = (
'A,B,C,D'
'x,y,xc,fgh'
'1,2,456,6789')
TabOrder = 0
OnClick = ListBox1Click
end
object ComboBox1: TComboBox
Left = 312
Top = 8
Width = 209
Height = 24
Style = csDropDownList
ItemHeight = 16
TabOrder = 1
OnChange = ComboBox1Change
end
object Label1: TLabel
Left = 312
Top = 40
Width = 41
Height = 16
Caption = 'Label1'
end
object ListBox2: TListBox
Left = 384
Top = 40
Width = 137
Height = 169
ItemHeight = 16
TabOrder = 2
OnClick = ListBox2Click
end
Then add the event handlers as shown below to the .cpp
//---------------------------------------------------------------------------
#include <vcl.h>
#pragma hdrstop
#include "MainFormUnit.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"
TForm1 *Form1;
//---------------------------------------------------------------------------
__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
}
//---------------------------------------------------------------------------
void __fastcall TForm1::ListBox1Click(TObject *Sender)
{
ComboBox1->Items->CommaText =
ListBox1->Items->Strings[ListBox1->ItemIndex];
ListBox2->Items->Assign(ComboBox1->Items);
}
//---------------------------------------------------------------------------
void __fastcall TForm1::ComboBox1Change(TObject *Sender)
{
Label1->Caption =
ComboBox1->Items->Strings[ComboBox1->ItemIndex];
}
//---------------------------------------------------------------------------
void __fastcall TForm1::ListBox2Click(TObject *Sender)
{
ComboBox1->ItemIndex =
ComboBox1->Items->IndexOf(ListBox2->Items->Strings[ListBox2->ItemIndex]);
}
//---------------------------------------------------------------------------
Compile, link and run. This seems to work as one would expect. I believe
it is a fair analogy to your program as described. Let me know if it
helps.
To test it, click first on the left most listbox (any entry) to populate
the combo and the rightmost list box. Then click on an element of the
rightmost list box and the corresponding entry will appear in the combo.
Ted Byers
> Hi, Ted!
>
> The idea of items vanishing is perhaps significant of a problem in your
> code. It is not normal TComboBox behavior.
>
Your example does indeed work as advertised. The next question is, then,
why do the combobox items vanish on me.
The code I use to add items to the combobox is like the following:
{
TMyElementEntryForm* boss;
boss = static_cast<TMyElementEntryForm*>(Owner);
if (!boss) exit(EXIT_FAILURE);
parents = new TStringList;
elements = boss->getElements();
element_map_type::iterator IT = elements->begin();
while (IT != elements->end()) {
if ( (*IT).second.getRadioactive() )
parents->Add((*IT).second.getName().c_str());
IT++;
};
ParentCMBO->Items = parents;
}
I find if I put this into the onEntry event of the combobox, on all of my
other forms, everything works as expected, but then in the other forms the
items are not accessed by anything other than the combobox when it has the
focus, and the data is not limited to the items already in the list (new
items being added to the list as required). elements is a STL map. One
item of note is that some of the data contained in refs and elements may be
added to the maps immediately prior to opening this form, so I can't put
this code into the form constructor (unless I want to create and destroy it
each time the user wants to add or edit this data).
'elements' is a data member of the form.
There is no chance new elements will be added while this form is open.
Is there something about adding this data in the onEntry event, or using a
TStringList, to put the items into the combobox that might account for the
vanishing items? In which event would you put this, or should I put it into
a member function of this form that is called by the owning form?
The way data is added to the Items member of the combobox is the only
significant difference I can see in how we are using them.
Cheers
Ted
Mark Cashman (TeamB)
ParentCMBO->Items->Assign(parents);
What you are doing in your version is wiping out the pointer to the
internally held string list and replacing it with your own, which,
apparently, is not working out well... (grin).
The Assign function will copy the "parents" elements to the Items string
list.
Mind you, you can also use...
ParentCMBO->Items->Add((*IT).second.getName());
...if you don't actually use "parents" for anything but loading the
Ted Byers
> Hi, Ted!
>
> ParentCMBO->Items->Assign(parents);
>
> What you are doing in your version is wiping out the pointer to the
> internally held string list and replacing it with your own, which,
> apparently, is not working out well... (grin).
>
I'll give that a try. I had seen the method I used in a book, but I have
forgotten which one. Just goes to show you can't always rely on what you
read.
Anyway, this gets us to a question of memory management. When I trash the
pointer to the internally held string list, shall I assume that, as in
standard C++, that produces a memory leak? If so, I ought to 'fix' the
other forms that appear to be functioning properly.
And what about the examples I have seen where one gives a TBitmap to a
TImage using something like:
myImage->Picture->Bitmap = bmp;
I was always curious about that, especially because the image classes have,
as I recall, an Assign member function like that for the string list you
mention above. Does it work in the same way?
If these were standard C++ classes, I had created myself, I'd make sure that
the Bitmap member wasn't pointing to anything before assigning to it, but I
recall seeing an example were this was done, which had a comment to the
effect that with the VCL TImage class, it disposes of the bitmap resources
it previously had when given a new bitmap in this way. I have never been
comfortable with this. It seems like behaviour I'd associate with reference
counted classes, but I do not know how you can make it happen with pointers,
unless we are dealing with really fancy reference counted auto-pointer
classes. With the VCL image classes, I am worried about who controls the
memory when transferring images using the methods in the examples I have
seen. And although I have seen a number of examples creating TBitmaps, the
bitmaps don't get owners that will handle deleting them, but none of the
examples I have seen delete a bitmap after assigning it to a TImage, leading
to the impression that the TImage handles freeing them.
And what does the TImageList do to this? Does it share ownership of the
TBitmap with the TImage? What strangeness would lead a TBitmap to be shrunk
dramatically when given to a TImageList, as compared with being given
directly to a TImage?
Would you mind clarifying memory management issues when working with these
components, and the suitability of using the assignment operator as opposed
to the Assign member function? I would repeat that in C++ classes I have
written myself, I'd be testing a pointer to see if it is pointing to
anything before assigning to it, yet this is not done in the VCL examples I
have seen.
Thanks,
Ted
Ted Byers
Mark Cashman (TeamB) <mcas...@temporaldoorway.com> wrote in message
news:395CE1B2...@temporaldoorway.com...
> Hi, Ted!
>
> ParentCMBO->Items->Assign(parents);
>
> What you are doing in your version is wiping out the pointer to the
> internally held string list and replacing it with your own, which,
> apparently, is not working out well... (grin).
>
> list.
>
> Mind you, you can also use...
>
> ParentCMBO->Items->Add((*IT).second.getName());
>
> ...if you don't actually use "parents" for anything but loading the
> combo.
>
I followed your suggestion, and on the assumption that the data would be
retained between data entries, I moved the code to initialize the comboboxes
to the onShow event handler as follows:
void __fastcall TNuclearReactionsForm::FormShow(TObject *Sender)
{
TMyElementEntryForm* boss;
boss = static_cast<TMyElementEntryForm*>(Owner);
if (!boss) exit(EXIT_FAILURE);
refs = boss->getReferences();
elements = boss->getElements();
element_map_type::iterator IT = elements->begin();
while (IT != elements->end()) {
ChildCMBO->Items->Add((*IT).second.getName().c_str());
if ( (*IT).second.getRadioactive() )
ParentCMBO->Items->Add((*IT).second.getName().c_str());
IT++;
};
}
There are two combo boxes and, while only radioactive elements ought to be
used in the parent combobox, all elements are possible products of
radioactive decay: hence the logic of what you see above.
Doing this brought two problems, or shall I say, added a new problem to the
original problem of vanishing data. In the latest test, the above code is
the only code that gives data to the comboboxes. Once I have made a
selection for each of the comboboxes (and an entry for an edit box - and
copied the data to a string grid), when I return to either of the
comboboxes, I find nothing in the combobox drop down list. The problem of
vanishing data remains.
The new problem is that with the above code, all entries in the elements
list are duplicated in both comboboxes. It looks as if the comboboxes were
sharing an instance of the TStringList member, but that does not make sense
since it would preclude having more than one combobox on a form, each of
which having different data.
Note, the c_str() is necessary since the keys used in the refs and elements
collections are STL strings, and BCB 5 isn't smart enough to convert between
them (I would have expected that Borland would have overloaded the
assignment operators for each to convert between them transparently).
To verify I have not lost my mind, would you mind running a test in which
you have an stl container, populated programmatically with random data (I am
using a map, if that matters), and use that to initialize a combobox in the
form's onShow event, and have an entry field to which you copy the combobox
text member when a command button is pushed, and tell me if you see
duplicate entries in the combobox drop down list which disappear when you
use the button to copy the text to the entry field. If that does not
duplicate what I am seeing entirely, the next step would be to duplicate the
above logic, using a pair of comboboxes and some seletion criterion
analogous to my use of radioactivity to select items for the parent combobox
(this might be necessary to duplicate my problem of duplicate entries.
I do not know how I can be messing up. The above coe is so simple, it ought
to be hard to get wrong. :-(
I still do not see what could amount to a significant difference between
what I am doing above and the example you gave.
Damn!
I just had a nasty thought.
I had the following code in the click event handler for my command button
(used for copying the data to the string grid). The behaviour required is
that once the data has been copied to the grid, all fields in the data entry
portion of the form ought to be empty awaiting the next entry.
{
...
ParentCMBO->Clear();
ChildCMBO->Clear();
HalfLife->Clear();
};
HalfLife is just a text entry field (TEdit). I did this on the assumption
that Clear() just clears the entry field, based on experience with TMemo and
TEdit. Could it be that this function also kills my combobox's list data?
If so, a) how do I clear the field while leaving the list data intact? And
b) how do we give Borland a slap for allowing such counter-intuitive
behaviour (I would have expected a different function to be used for
emptying the TStringList member, whenever that is necessary)? But if this
is behind my vanishing list data problem, there remains the problem of
duplicate entries in both comboboxes when I put the initialization code in
the form's show even handler. The show event would not happen twice for
each appearance of the form, would it (it occurs to me that I'll have to add
logic to compare the contents of the owner's element list with those in the
form's list, to track changes, and only add items to the combobox that are
not alreayd there, just in case the form gets closed and reopened, or
perhaps just empty the lists as add the contents of the container, since I'd
have to iterate throught the container anyway looking for new data, and that
would involve comparing each of the n strings in the container with each of
the m strings in the combobox list)? The data in the comboboxes ought to be
guaranteed to be current once the form shows, but it is not going to change
until after the form closes, so the onShow event seems to be the most
appropriate spot for doing this.
Any further suggestions?
Thanks for all your help. I greatly appreciate it.
Cheers,
Ted
R.E. Byers
rtb...@bconnex.net
Ted Byers
There is no need to run any further tests.
My nasty hunches proved to be correct. (So we need to give Borland a slap
for rather counter intuitive behaviour of the clear function of the
combobox)
I added code to clear the comboboxes' lists on entry into the FormShow event
handler, and that dealt with the duplicate data in the lists. And I made
the following change to my click even handler for my command button, and
this solved the problem of vansihing data.
// ParentCMBO->Clear();
// ChildCMBO->Clear();
HalfLife->Clear();
ParentCMBO->Text.Delete(1,ParentCMBO->Text.Length());
ChildCMBO->Text.Delete(1,ChildCMBO->Text.Length());
Clearly clear() was killing my list data (when the way I would have handled
this would have been ParentCMBO->Items->Clear - which would clear the list
if that was what I wanted to do, leaving ParentCMBO->Clear() to clear only
the entry field).
Thanks for your help.
I would still appreciate clarification of the memory management issues this
problem raised, that I asked about this afternoon, if you don't mind.
Thanks,
Ted
J Gardiner
Sorry to upset this thread by referring to your original contention
*TComboBox...broken...*.
I wish to add my support your contention that TComboBox has some (serious)
defects.
I don't see any mention of what BCB you are using (4 or 5).
With BCB4 there is definitely a very serious defect in another area, not related
to your problem I think.
I wanted to change the Combobox style on the *OnEnter* and *OnExit* events.
With BCB4 I get an AV; with BCB5 no AV but the control behaves differently
depending on whether you enter via *Click* or *Tab* to the control.
John
Ted Byers
Having solved the problem, it appears it is a question of poor documentation
and rather counterintuitive behaviour of the Clear() member function.
I am using BCB 5, but while I have been using the onEnter event, I have not
noticed any strangeness in how it behaves WRT tabbing in VS clicking on the
control. How do they appear different to you?
J Gardiner
Ted Byers wrote:
> How do they appear different to you?
Put Edit1, ComboBox1, Edit2 on a form in that tab order.
Put a few Items in the ComboBox.
Set the *OnEnter* and *OnExit* as per listing below (without the comments.)
When I compile and run:
No surprises if I cycle through the components using *Tab*
If I *Click* the ComboBox, the appearance is ok (Style is csDropDown) but button
is dead until I first click somewhere in the text area, even though the *Down*
and *Up* arrows select the ComboBox items correctly.
Using the very sophisticated *Shotgun* design method (try anything that comes to
mind) I had no success with the code shown commented.
Next step: go to the news-group, *TComboBox appears to be slightly broken*
looked like a good start!
(Want the rest of my life-story? ..... no! don't answer!)
void __fastcall TForm1::cb1Enter(TObject *Sender)
{
cb1->Style = csDropDown;
cb1->SelectAll();
// cb1->SetFocus();
// cb1->UpdateControlState();
// cb1->Update();
// cb1->Invalidate();
}//----------------------------------------
void __fastcall TForm1::cb1Exit(TObject *Sender)
{
cb1->Style = csSimple;
}//----------------------------------------
John
Ted Byers
> When I compile and run:
> No surprises if I cycle through the components using *Tab*
> If I *Click* the ComboBox, the appearance is ok (Style is csDropDown) but
button
> is dead until I first click somewhere in the text area, even though the
*Down*
> and *Up* arrows select the ComboBox items correctly.
I tested the situation you described. The only unusual thing I saw was that
the arrow for the combobox was not visible unless it had the focus. This is
using only the code you provided. When I comment out the line in the exit
event handler that sets the style to csSimple, even that oddity vanished and
all means of using it resulted in the expected behaviour. Was there a
reason you set the style to csSimple when it is not in use? I do not see
how that helps when you set it to csDropDown on entry. Why not just leave
it csDropDown? Anyway, at no time did I see a disabled or dead button.
Sorry I can't help. I can't explain why I see something different from what
you have described.
Mark Cashman (TeamB)
Generally, you should check the help for the component property type /
class you wish to assign to. If that help shows an override of operator
=, then direct assignment is safe. Delphi doesn't offer operator
overloading, so with the VCL based on Delphi, Assign is generally safer.
I am not sure whether or not the overridden "=" is common in BCB.
If you assign over a pointer, it is a memory leak unless the pointer is
to an object owned by something that will destroy it later.
I am not sure if you need more than that. Please feel free to post if
that is not enough.
Ted Byers
Mark Cashman (TeamB) <mcas...@temporaldoorway.com> wrote in message
news:3963A514...@temporaldoorway.com...
> Hi, Ted!
>
> Generally, you should check the help for the component property type /
> class you wish to assign to. If that help shows an override of operator
> =, then direct assignment is safe. Delphi doesn't offer operator
> overloading, so with the VCL based on Delphi, Assign is generally safer.
> I am not sure whether or not the overridden "=" is common in BCB.
>
It is not over-ridden in the TBitmap, TImage and TPicture classes, which are
the ones I use most for my graphics.
> If you assign over a pointer, it is a memory leak unless the pointer is
> to an object owned by something that will destroy it later.
>
> I am not sure if you need more than that. Please feel free to post if
> that is not enough.
>
Well, based on this I did the following (because TBitmap does not have an
owner to take care of deleting it), and encountered a problem with freeing
memory held by bitmaps. Everything else that I am doing with these bitmaps
and the STL vector works flawlessly!
The typedef and relevant include:
#include <vector>
using std::vector;
typedef vector<Graphics::TBitmap*> bmpListType;
The declaration:
bmpListType *bmps;
The initialization:
bmps = new bmpListType[numYears];
The problem code:
__fastcall TMetForm::~TMetForm()
{
Graphics::TBitmap *bmpPTR;
if (!bmps) return; // nothing to delete in this case
bmpListType::iterator IT;
for (int i = 0 ; i < nYears ; i++ ) {
if (bmps[i].size() > 0) {
IT = bmps[i].begin();
while (IT != bmps[i].end()) {
bmpPTR = *IT;
delete bmpPTR;
};
};
};
delete [] bmps;
}
The problem is that the loop in the problem code gives
an access violation when only about two or three bitmaps
have been deleted, when we know beforehand that each bitmap
list has precisely 36 bitmaps and that nYears has a minimum
value of one if bmps has been initialized. I do not understand why
the above code should produce an access violation.
bmps holds only pointers, so I need to iterate through and free the
memory addressed by the pointers, right?
And I assume, from what you said above, that if I create a TBitmap
that if I want to store in a TImage, I need to do something like the
following:
Graphics::TBitmap *bmpPTR = new Graphics::TBitmap;
Graphics::TBitmap *tmpPTR
... draw on bmpPtr
tmpPTR = theImage->Picture->Bitmap; // theImage is a TImage created at
design time on the form
if (tmpPTR) delete tmpPTR;
theImage->Picture->Bitmap = bmpPTR; // or
theImage->Picture->Bitmap->Assign(bmpPTR);
delete bmpPTR;
This last line does not make sense since if the above line is just a pointer
assignment, it should produce
an access violation when the image tries to do something with the bitmap,
yet when I hold a number of
bitmap pointers in an STL vector, and assign one of them to anTImage, and
then draw on the image,
the drawing does NOT appear on the bitmap in the vector. Instead, it
behaves as if a copy constructor had been invoked and the image given a copy
of the original bitmap instead of just the address of the bitmap, since to
make it appear on the bitmap stored in the vector I have to draw it there
ALSO, and this implies that a TBitmap ought to be deleted after being
assigned to a TImage. This is part of what makes the memory management in
VCL rather confusing. This behaviour with TBitmap and TImage is decidedly
non-standard C++ behaviour.
Any clarification would be greatly appreciated.
Thanks,
Ted
Mark Cashman (TeamB)
the VCL source and find out what is really happening. I'm afraid my time
won't permit a detailed look.