PeterBelow

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?

Real professionals have to earn money with their works, they don't have the time to reinvent the wheel, debug and validate it. If you want to shoot yourself in the foot be my guest, but don't expect me to supply the bullets...

Attached find a little example program that definitely works . FileEncryption.zip

You don't need to install the component, it is just a convenience wrapper. I'll try to create a small demo over the weekend, no time at the moment.

Make sure that all modal forms have PopupMode set to pmAuto and in the dpr file you have Application.MainformOnTaskbar := true; That avoids such isssues at least on classic Windows systems. I know nothing about Windows RD Web, though.

I use Lockbox 3 for such purposes.