PeterBelow

Not with a TDBEdit. Databound controls are typically linked to one single record (the current record in the dataset); using them the typical workflow is: add new record - enter data for this record - post the record to the dataset. You have to use an unbound TEdit in your case and dissect its content in code, e.g. when the user leaves the control (OnExit event), or when he pushes a button. Pseudo code: var LList: TStringlist; N, LValue: integer; begin LList := TStringlist.Create; try LList.StrictDelimiter := True; LList.Commatext := Edit1.Text; for N:= 0 to LLIst.Count - 1 do begin if TryStrToInt(Trim(LList[N]), LValue) then begin add record to dataset store LValue into the dataset field post the record end; {if} end; {for} finally LList.Free; end; end;

I get no exception using D11.1 with this code.

For database BLOB fields you generally cannot use a generic TStream, you need to ask the BLOB field to create a TBlobStream descendant specific for the database engine in question. In your case you first create the blob stream for the local database, store the field content in it, the create a blob stream for the server database, copy the content of the first stream to it, then load the contents into the server db field.

The IDE uses separate layouts/desktops for editing and debugging. You have to adjust the debug layout to your requirements, save it under a name of your own, and then make that the default debug layout.

Records are value types, so adding a record to a TDictionary<recordtype> adds a copy of the record to the internal storage, and Remove then clears up that copies memory. So there are no leaks, but adding a record and getting it back later always makes a full copy of the record, which can be a bit hard on performance.

In my opinion source files you want to protect from modification should be located in a folder tree the user you are working with does not have write access to. Don't use an admin account to work in the IDE!

It means that the JasotComponents package has DAScript listed in its "contains" clause while also listing dac280 in the "requires" clause. You have to remove the unit from the "contains" clause. In a package collection (packages that depend on others in the collection) each unit can only be contained in one single package. Complex package collections can drive you berserk if you have to build them manually, without a manufacturer-supplied build script.

If the dcp file for the package is there and in the search path you just have to add that package to the requires clause of the design-time package, that should eliminate all these warnings.

Well, the warning means that the unit in question was not found in any of the packages named in the "requires" clause and, since it was not in the "contains" clause of the package, had to be added to build the package. This is not in itself an error and will not cause the build to fail, but it is an indication that there should be a run-time package available which contains the unit and should be added to the design-time packages "requires" clause. You may have to build that run-time package first, though.

unit TestbedU1; interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, System.Classes, Vcl.ComCtrls; type TForm1 = class(TForm) ViewButton: TButton; Edit1: TEdit; ListView1: TListView; Memo1: TMemo; CheckButton: TButton; UncheckButton: TButton; procedure CheckButtonClick(Sender: TObject); procedure FormCreate(Sender: TObject); procedure UncheckButtonClick(Sender: TObject); procedure ViewButtonClick(Sender: TObject); strict private procedure SetCheckstate(aListview: TListView; Value: Boolean); private public { Public declarations } end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.CheckButtonClick(Sender: TObject); begin SetCheckstate(listview1, true); end; procedure TForm1.FormCreate(Sender: TObject); const ColCaptions: array [0..3] of string = ( 'Zero','One','Two','Three'); var I: Integer; LCol: TListColumn; LItem: TListItem; N: Integer; begin memo1.Clear; listview1.ViewStyle := vsReport; listview1.Checkboxes := true; listview1.MultiSelect := true; for I := 0 to 3 do begin LCol:= listview1.Columns.Add; LCol.Caption := ColCaptions[I]; LCol.AutoSize := true; end; for I := 1 to 5 do begin LItem:= listview1.Items.Add; LItem.Caption := Format('Item %d',[I]); for N := 1 to 3 do LItem.SubItems.Add(Format('Item %d%d',[I, N])); end; end; procedure TForm1.ViewButtonClick(Sender: TObject); const State: array [boolean] of string = ('not',''); var I: Integer; LItem: TListItem; begin for I := 0 to listview1.items.count-1 do begin LItem:= ListView1.Items[I]; memo1.Lines.Add( Format( 'Item %d is %s checked.', [Succ(I), State[LItem.Checked]]) ); end; end; procedure TForm1.SetCheckstate(aListview: TListView; Value: Boolean); var I: Integer; LItem: TListItem; begin for I := 0 to listview1.items.count-1 do begin LItem:= ListView1.Items[I]; if LItem.Selected then LItem.Checked := Value; end; end; procedure TForm1.UncheckButtonClick(Sender: TObject); begin SetCheckstate(listview1, false); end; end. TestbedU1.dfm TestbedU1.pas

When you deverlop a custom component it is a good idea to use a test project first in which you create an instance of the component in code. This allows you to debug the run-time behaviour of the component without endangering the IDE itself. Only when everything works as it should do you add it to a design-time package and install it, to validate the design-time behaviour. If you need to add a custom property or class editor these can also be developed and tested in the test project, by just doing what the IDE designer does for invoking them. I don't remember the details since it has been literally decades since I last needed to do this, but it can be done.

In the IDE: Run -> Parameters

The error message suggests that a component on one of the autocreated forms has not been created yet when some other component tries to refer to it when the IDE designer loads the form. This may be a sequence problem. Try to change the autocreation sequence to create the datamodule before the forms.

Never rely on relative path names! They depend on whatever the application thinks the "current directory" is, and that is frequently not what you think it should be. Have you checked what destPath contains after your assignment?

Have you tried the obvious: AssignFile(F, 'c:\tmp\test.txt'); Reset(F); for i := Low(CompanyDataBase) to High(CompanyDataBase) do Read(F, CompanyDataBase[I]); CloseFile(F);

Have you added simdesign-master\simlib\debug to the project search path?

Object references are not automatically managed by the compiler-generated code, unlike interface references. So your code has a couple of possible problems re lifetime control: If the assignment just replaces the RootObject.Objectlist (the internal reference held by RootObject) you leak the old object list's memory, as well as the objects held by the old list. After the assignment you now have two object list references referring to the same objectlist instance, one in RootObject.Objectlist, the other in Helper.DrawingObjectlist. If you free one the other becomes invalid and will cause an AV when next accessed. If the assignment resolves to a call to a setter method (i.e. RootObject.Objectlist is a property with a setter method) and the setter frees the old reference before storing the one passed in you do not leak memory for the old list, but you still have two references to the same object list, with the problems mentioned above. If the assignment resolves (via setter method) to clearing the content of the internal list first (assuming OwnsObject = true, so the contained objects are freed) and then storing the content of the passed list into the internal list you don't have the two problems mentioned in the first bullet point, but you have another: you now have two lists holding references to the same objects. Free an object in one list and the reference in the other becomes invalid. Especially fun if both lists have OwnsObjects set to true. If the assignment resolves (via setter method) to clearing the content of the internal list first (assuming OwnsObject = true, so the contained objects are freed) and then moving the content of the passed-in list to the internal one you don't have a memory management problem, but the source list is now empty after the assignment. That may not be acceptible, depending on your requirements. There are two ways out of this mess: Change the design from using object references to using interface references. This gives you automatic lifetime control of the objects behind the interfaces via reference counting. Implement a deep copy mechanism for the objects held in the lists. The assignment would then clear the old content of the list and then store copies (clones) of the objects in the source list into the internal list. This way the two lists are completely independent of each other, changing objects in one has no effect on the objects in the other. Both lists can have OwnsObject = true and there will be no memory leaks.

Well, Delphi has the System.NetEncoding.TBase64Encoding class you can use for the first step to convert the string to an array of bytes (TBytes) or put it into a stream directly, e.g. a TMemorystream. The decryption is a different matter, though. There was a recent thread on using the free Lockbox 3 library for this purpose on these groups. See here...

Just to explain your problem: the VCL creates window handles on an as needed basis, which may delay this action until the window is shown and needs to be drawn. In your example (without Synchronize) this causes the window handle to be created in the background thread, not the main thread, and that thread has no message loop...

Your test case is in error, your value i has all top 32 bits set to zero.

Set the ParentBackground property of the panel to true.

After opening the project go to the Project Manager pane; it's docked to the right of the editor by default. Under the project node you should have a noded named "Target platforms". Right-click on it to get a menu with an "Add platform" caption. Click that to get a list of available platforms, select "Windows 64 bit" from that. You should now have two subnodes under "Target platforms", double-click on the one you want to build to activate it.

Do it on the string itself, like you learned addition in school. function incrementID(const aID: string):string; var ch: Char; N: Integer; begin Result := aID; N:= Length(Result); while N > 0 do begin ch := Result[N]; case ch of '0'..'8': begin Result[N] := Succ(ch); Break; end; '9': begin Result[N] := '0'; Dec(N); end; '.': Dec(N); else raise Exception.CreateFmt('Invalid character "%s" in ID "%s" at position %d.', [ch, aID, N]); end; {case ch} end; {while} end;

You can change the visibility of properties inherited from an ancestor, you cannot do that with fields. The VCL itself makes heavy use of that.

As far as I can see this function does not wait at all, it just checks the task value and returns. Or does the getter for FTask.Value wait?