I would like to use the gallery pictures (Metal, Wood, Stone, Clouds, etc.) which are available at design time under Chart/Panel/Image/Gallery.
If I set it at design time, I can easily disable it at run time with:
g.backImage := nil;
But if I want to set it to a particular value, e.g. with
g.backImage := 'metal';
I get an 'Incompatible types' error, because the compiler requires a TBackImage value. I do not have the source codes, and I cannot find the appropriate values on several Google searches.
Thinking that it could be just an enum, I tried typecasting it to one:
g.backImage := TBackImage(1);
But it generates an exception. I also tried to "guess" the names, like tbiMetal, tbMetal, tMetal, and so on, to no avail...
What are those values?! Thank you
TBackImage is a class whose methods you must call.
Chart.BackImage.LoadFromFile('full/path/to/imagefile');
Those are real texture images embedded in TBrushDialog, they can be used/accessed like this:
uses TeeBrushDlg;
procedure TForm1.FormCreate(Sender: TObject);
var BrushDialog: TBrushDialog;
begin
BrushDialog:=TBrushDialog.Create(Self);
Chart1.BackImage.Graphic:=BrushDialog.ImageCarbon.Picture.Graphic;
end;
Related
IDE: c++ Builder XE5 Update 2
TeeChart Build: 2014.11.140512
I am trying to bring certain series on a TChart component to the front(as you would typically do with a BringToFront() function).
I've done some reading and found the following options/suggestions:
A. Change the ZOrder property of the series.
B. Use TChart.ExchangeSeries()
Using TChart.ExchangeSeries() is not a proper way of changing the z-order of a series. Its primary function is to swap around two series in a TChart component's SeriesList(which then inherently changes the z-order of those series). If you require your series-ordering to be fixed(fixed ordering in SeriesList), then this will not work.
Changing the ZOrder properties of the series delivered better results. However, changing the ZOrder of the first series(Series[0]) apparently does nothing. Series[0] seem to like sitting at the back of the class.
The above might be the result of my implementation. In which case, some more details:
On my TChart component I have multiple series. The series-types can be changed dynamically. The types to which the series can be changed are limited to TLineSeries and TBarSeries.
I always want the TLineSeries at the front.
Any advice on how this can be done?
(Will we ever see that elusive TChartSeries.BringToFront() function?) :)
Any advice on how this can be done?
Looks like mixing series styles and changing ZOrder is not working very well. For example, using this code snippet:
uses Series;
procedure TForm1.FormCreate(Sender: TObject);
begin
Chart1.AddSeries(TLineSeries.Create(Self)).FillSampleValues(10);
Chart1.AddSeries(TLineSeries.Create(Self)).FillSampleValues(10);
Chart1.AddSeries(TBarSeries.Create(Self)).FillSampleValues(10);
Chart1.AddSeries(TBarSeries.Create(Self)).FillSampleValues(10);
Chart1.AddSeries(TBarSeries.Create(Self)).FillSampleValues(10);
end;
procedure TForm1.Button1Click(Sender: TObject);
var i: Integer;
begin
for i:=0 to Chart1.SeriesCount-1 do
begin
Chart1[i].Marks.Visible:=False;
if Chart1[i] is TLineSeries then
Chart1[i].ZOrder:=Chart1.SeriesCount - 1 - i
else
Chart1[i].ZOrder:=i;
end;
end;
Line series are brought to the front but bar series style remain there. I have also tried with bar series StackGroups: However, it doesn't make much of a difference. We'd need StackGroups for line series as well for this work.
(Will we ever see that elusive TChartSeries.BringToFront() function?)
:)
Why not? I have added your request to Steema Software's bugzilla platform: http://bugs.teechart.net/show_bug.cgi?id=853. Feel free to sign up and add yourself to the CC List to receive automatic issue updates.
Regards for all Delphi Guru :)
I have table in Access 2010, one of the column type is OLE Object named "ProductImage"
I use that column to save Bitmap Image.
The problems is, How can I display that image using DBImage or TImage in Delphi 7?
I've tried this
procedure TF_Search2.DBGrid1CellClick(Column: TColumn);
begin
Image7.Picture.Assign(DataModule1.T_Products.FieldByName('ProductImage').LoadFromFile('c:\test.jpg'));
end;
It's error : need parameter in this part 'LoadFromFile('c:\test.jpg')'
I tried also using "TBlobField", but I got error : undeclared identifier TBlobField
I read that it should in unit and uses. I don't understand what's that mean.
Should I add something on installation folder or what?
Any helps would be appreciated.
Thank You
The field also contains an OLE Header. I ancient times I skipped this (I think the first 79 bytes) but I cannot find the code anymore. However, the internet has solutions as always. Imho this one is better than my 'skip' solution.
Here is one of them:How to read and write images from/to an access DB (page 4)
EDIT: I just saw that your problem is your syntax.
procedure TF_Search2.DBGrid1CellClick(Column: TColumn);
begin
Image7.Picture.Assign(DataModule1.T_Products.FieldByName('ProductImage').LoadFromFile('c:\test.jpg'));
end;
This is not valid delphi syntax and quite confusing. The Picture.Assign method expects a picture object. So what you first would want to do is to get the picture out of the access-DB.
You want to read the image data from an access db and display it in an image component?
Follow the steps in the link.
EDIT: I did find some very old code which I modified (and cannot test):
aBitmapStream := TMemoryStream.Create;
tblDrawing_BitmapColumnBLobField.SaveToStream (aBitmapStream);
// This hack enables Access BMP-Blobs to be imported
aBitmapStream.Seek (78,soFromBeginning);
myBitmap := TBitmap.Create;
myBitmap.LoadFromStream (aBitmapStream);
Image7.Picture.Assign (myBitmap);
myBitmap.Free;
aBitmapStream.Free;
I subclassed a control in order so I can add a few fields that I need, but now when I create it at runtime I get an Access Violation. Unfortunately this Access Violation doesn't happen at the place where I'm creating the control, and even those I'm building with all debug options enabled (including "Build with debug DCU's") the stack trace doesn't help me at all!
In my attempt to reproduce the error I tried creating a console application, but apparently this error only shows up in a Forms application, and only if my control is actually shown on a form!
Here are the steps to reproduce the error. Create a new VCL Forms application, drop a single button, double-click to create the OnClick handler and write this:
type TWinControl<T,K,W> = class(TWinControl);
procedure TForm3.Button1Click(Sender: TObject);
begin
with TWinControl<TWinControl, TWinControl, TWinControl>.Create(Self) do
begin
Parent := Self;
end;
end;
This successively generates the Access Violation, every time I tried. Only tested this on Delphi 2010 as that's the only version I've got on this computer.
The questions would be:
Is this a known bug in Delphi's Generics?
Is there a workaround for this?
Edit
Here's the link to the QC report: http://qc.embarcadero.com/wc/qcmain.aspx?d=112101
First of all, this has nothing to do with generics, but is a lot more likely to manifest when generics are being used. It turns out there's a buffer overflow bug in TControl.CreateParams. If you look at the code, you'll notice it fills a TCreateParams structure, and especially important, it fills the TCreateParams.WinClassName with the name of the current class (the ClassName). Unfortunately WinClassName is a fixed length buffer of only 64 char's, but that needs to include the NULL-terminator; so effectively a 64 char long ClassName will overflow that buffer!
It can be tested with this code:
TLongWinControlClassName4567890123456789012345678901234567891234 = class(TWinControl)
end;
procedure TForm3.Button1Click(Sender: TObject);
begin
with TLongWinControlClassName4567890123456789012345678901234567891234.Create(Self) do
begin
Parent := Self;
end;
end;
That class name is exactly 64 characters long. Make it one character shorter and the error goes away!
This is a lot more likely to happen when using generics because of the way Delphi constructs the ClassName: it includes the unit name where the parameter type is declared, plus a dot, then the name of the parameter type. For example, the TWinControl<TWinControl, TWinControl, TWinControl> class has the following ClassName:
TWinControl<Controls.TWinControl,Controls.TWinControl,Controls.TWinControl>
That's 75 characters long, over the 63 limit.
Workaround
I adopted a simple error message from the potentially-error-generating class. Something like this, from the constructor:
constructor TWinControl<T, K, W>.Create(aOwner: TComponent);
begin
{$IFOPT D+}
if Length(ClassName) > 63 then raise Exception.Create('The resulting ClassName is too long: ' + ClassName);
{$ENDIF}
inherited;
end;
At least this shows a decent error message that one can immediately act upon.
Later Edit, True Workaround
The previous solution (raising an error) works fine for a non-generic class that has a realy-realy long name; One would very likely be able to shorten it, make it 63 chars or less. That's not the case with generic types: I ran into this problem with a TWinControl descendant that took 2 type parameters, so it was of the form:
TMyControlName<Type1, Type2>
The gnerate ClassName for a concrete type based on this generic type takes the form:
TMyControlName<UnitName1.Type1,UnitName2.Type2>
so it includes 5 identifiers (2x unit identifier + 3x type identifier) + 5 symbols (<.,.>); The average length of those 5 identifiers need to be less then 12 chars each, or else the total length is over 63: 5x12+5 = 65. Using only 11-12 characters per identifier is very little and goes against best practices (ie: use long descriptive names because keystrokes are free!). Again, in my case, I simply couldn't make my identifiers that short.
Considering how shortening the ClassName is not always possible, I figured I'd attempt removing the cause of the problem (the buffer overflow). Unfortunately that's very difficult because the error originates from TWinControl.CreateParams, at the bottom of the CreateParams hierarchy. We can't NOT call inherited because CreateParams is used all along the inheritance chain to build the window creation parameters. Not calling it would require duplicating all the code in the base TWinControl.CreateParams PLUS all the code in intermediary classes; It would also not be very portable, since any of that code might change with future versions of the VCL (or future version of 3rd party controls we might be subclassing).
The following solution doesn't stop TWinControl.CreateParams from overflowing the buffer, but makes it harmless and then (when the inherited call returns) fixes the problem. I'm using a new record (so I have control over the layout) that includes the original TCreateParams but pads it with lots of space for TWinControl.CreateParams to overflow into. TWinControl.CreateParams overflows all it wants, I then read the complete text and make it so it fits the original bounds of the record also making sure the resulting shortened name is reasonably likely to be unique. I'm including the a HASH of the original ClassName in the WndName to help with the uniqueness issue:
type
TWrappedCreateParamsRecord = record
Orignial: TCreateParams;
SpaceForCreateParamsToSafelyOverflow: array[0..2047] of Char;
end;
procedure TExtraExtraLongWinControlDescendantClassName_0123456789_0123456789_0123456789_0123456789.CreateParams(var Params: TCreateParams);
var Wrapp: TWrappedCreateParamsRecord;
Hashcode: Integer;
HashStr: string;
begin
// Do I need to take special care?
if Length(ClassName) >= Length(Params.WinClassName) then
begin
// Letting the code go through will cause an Access Violation because of the
// Buffer Overflow in TWinControl.CreateParams; Yet we do need to let the
// inherited call go through, or else parent classes don't get the chance
// to manipulate the Params structure. Since we can't fix the root cause (we
// can't stop TWinControl.CreateParams from overflowing), let's make sure the
// overflow will be harmless.
ZeroMemory(#Wrapp, SizeOf(Wrapp));
Move(Params, Wrapp.Orignial, SizeOf(TCreateParams));
// Call the original CreateParams; It'll still overflow, but it'll probably be hurmless since we just
// padded the orginal data structure with a substantial ammount of space.
inherited CreateParams(Wrapp.Orignial);
// The data needs to move back into the "Params" structure, but before we can do that
// we should FIX the overflown buffer. We can't simply trunc it to 64, and we don't want
// the overhead of keeping track of all the variants of this class we might encounter.
// Note: Think of GENERIC classes, where you write this code once, but there might
// be many-many different ClassNames at runtime!
//
// My idea is to FIX this by keeping as much of the original name as possible, but
// including the HASH value of the full name into the window name; If the HASH function
// is any good then the resulting name as a very high probability of being Unique. We'll
// use the default Hash function used for Delphi's generics.
HashCode := TEqualityComparer<string>.Default.GetHashCode(PChar(#Wrapp.Orignial.WinClassName));
HashStr := IntToHex(HashCode, 8);
Move(HashStr[1], Wrapp.Orignial.WinClassName[High(Wrapp.Orignial.WinClassName)-8], 8*SizeOf(Char));
Wrapp.Orignial.WinClassName[High(Wrapp.Orignial.WinClassName)] := #0;
// Move the TCreateParams record back were we've got it from
Move(Wrapp.Orignial, Params, SizeOf(TCreateParams));
end
else
inherited;
end;
This question is about being able to save routines, and being able to select them from a list…. When you select one it knows what to link where etc. Just for understanding. not the actual program
Say I want to create a routine in a Delphi form. And I want to create several different ones. They wont be exactly the same but some might be similar. I want to know how you can save things in Delphi and when you close or terminate the application they will remain remembered when you reopen it. I have no idea where to start and how to work this. Any help would be great. Just a hint or a direction, maybe a website with more info or even examples. I’m going to try to give a simpler description below about how it would look on the form…. Just for the idea and I think if I understand this then it would be enough, or a good start at least.
The form will contain a list box a save button and 4 different edit boxes. Lets say I type in edit1;1 and edit2;2 and edit3;3 and edit4;4. Then click the save button and it remembers these 4 value to each edit box and lets say saves in under the value in the list box of ≔edit1.text + ‘to’ + edit4.text. Hope it makes sense so far and then I type in the edit boxes everything the wrong way around. edit1;4 and edit2;3 and edit3;2 and edit4;1. And click save button and it does that again (≔edit1.text + ‘to’ + edit4.text) into the list box. Then I want to close the application. Open it again and still have this in there and still be able to add more of these odd samples….
Can anyone help me?
Edit question, might make it more clear....
I'm going to place the following elements on the form: 2 listboxes(with each 3 lines, in the first listbox: wood, plastic and glass. in the second listbox: tree,cup,window.)
Now I want to link the correct ones, they are in order here, but what is they were not. In a table or in a memory of the application which is not visible on the form I want to link them.
Then if i were to put two edit boxes on the form as wel and I type in the first one wood or tree, it places the other one in the other edit box. So in a way I suppose you are creating a table which knows which one correcsponds with which but also looksup up when you type in edit box. hope that makes sense
From what you wrote I assume that you already know how to add the values to remember to your list box, so I won't deal with this part here. Starting with this answer, you should already have a clue to what to look at in the delphi help files. Please be aware that I didn't test the example, so there may be typos in it.
To store data in the computers registry, delphi provides you with the unit Registry, which contains a class TRegistry.
TRegistry has all the methods needed to retrieve and store values. Following is a short example without any practical use, just to give you the picture. Please be aware that, like mentioned in the comments, there's plenty of room left for you to optimise it. It would, for example, be better to create the TRegistry object only once and then repeatedly call the methods. And - while this plain old delphi unit I wrote is syntactically valid - you might be better off using a more object-oriented approach, like deriving a new class from TRegistry. Please do also check the documentation for the return values of the methods, as some (like OpenKey) simply return false when they are unable to fulfill your request while others (like ReadString) can throw an execption.
unit Unit1;
interface
uses TRegistry, Windows;
procedure saveStringToRegistry(name : String; value : String);
function readIntegerFromRegistry(name : String) : Integer;
implementation
procedure saveStringToRegistry(name : String; value : String);
var r : TRegistry;
begin
r := TRegistry.Create;
try
r.RootKey := HKEY_CURRENT_USER; // Defined in unit Windows, as well as HKEY_LOCAL_MACHINE and others.
r.OpenKey('Software\Manufacturer Name\Produkt Name\Other\Folders',true); // TRUE allows to create the key if it doesn't already exist
r.WriteString(name,value); //Store the contents of variable 'value' in the entry specified by 'name'
r.CloseKey;
finally
r.Free;
end;
end;
function readIntegerFromRegistry(name : String) : Integer;
var r : TRegistry;
begin
r := TRegistry.Create;
try
r.RootKey := HKEY_LOCAL_MACHINE; // Defined in unit Windows
r.OpenKey('Software\Manufacturer Name\Produkt Name\Other\Folders',false); // FALSE: do not create the key, fail if it doesn't already exist
result := r.ReadInteger(name);
r.CloseKey;
finally
r.Free;
end;
end;
end.
OK, now you could use a for loop in your application to process all the items of your list box and save it to the registry using the procedure above, like this:
for i := 0 to ListBox1.Count -1 do
saveStringToRegistry('Entry' + IntToStr(i),ListBox1.Items[i];
Then, you would probably save the number of items you have (of course you would have to define the procedure saveIntegerToRegistry):
saveIntegerToRegistry('NumberOfEntries',ListBox1.Count);
When you need to reload the data, you could do:
ListBox1.Clear;
for i := 0 to readIntegerFromRegistry('NumberOfEntries') -1 do
ListBox1.Items.Add(readStringFromRegistry('Entry' + IntToStr(i));
OK, it's a very basic example, but should give you pointer in the right direction. It could of course need some exception handling (imagine the user accidently deleted Entry42 from the registry, but NumberOfEntries still says there are 55 entries).
I've given up on the Delphi 7 debugger and am pretty much relying on outputdebugstrings. Is there a standard function I can call to get the contents of an object as a string like the debugger would if I set a breakpoint?
Not exactly what your looking for, but you can use RTTI to get access to the values of various published properties. The magical routines are in the TypInfo unit. The ones you are probably most interested in are GetPropList which will return a list of the objects properties, and GetPropValue which will allow you to get the values of the properties.
procedure TForm1.DumpObject( YourObjectInstance : tObject );
var
PropList: PPropList;
PropCnt: integer;
iX: integer;
vValue: Variant;
sValue: String;
begin
PropCnt := GetPropList(YourObjectInstance,PropList);
for iX := 0 to PropCnt-1 do
begin
vValue := GetPropValue(YourObjectInstance,PropList[ix].Name,True);
sValue := VarToStr( vValue );
Memo1.Lines.Add(PropList[ix].Name+' = '+sValue );
end;
end;
for example, run this with DumpObject(Self) on the button click of the main form and it will dump all of the properties of the current form into the memo. This is only published properties, and requires that the main class either descends from TPersistent, OR was compiled with {$M+} turned on before the object.
Rumor has it that a "reflector" like ability will be available in a future version of Delphi (possibly 2010).
Consider something like Codesite which is a much more complete tracing solution. It allows you to output much more complex info, and then search, print, and analyse the data. But for your purposes, you can simply send an object to it with Codesite.Send('Before', self); and you get all the RTTI available properties in the log. Do an "After" one too, and then you can compare the two in the Codesite output just by selecting both. It's saved me many times.
if delphi 7 is the .NET version, then you could do (some of) that with reflection. (not easy, but not terribly hard). if it's the normal, compiled thing, then it's a hard problem and the debugger is you best bet, apart from specialized printing functions/methods.