PeterBelow

If you use the LoadMovie function in the code unit generated by the wizard you get an IXMLMovieType interface back. Its Uniqueid property returns an interface of type IXMLUniqueidTypeList, which derives from IXMLNodeCollection, so it represents a list of nodes (represented by IXMLUniqueidType interfaces), accessed via the Items property. The list interface inherits a Count property from IXMLNodeCollection, so you can write a classical for loop to iterate over the Items property to examine each of the UniqueId nodes, to find the one with the Type_ property you are looking for (note the underscore added to the property name by the wizard, to avoid a collision with the reserved word type).

Have you tried to use the correct UTF16 code points instead, e.g. #$2012 etc.? Check the proper codes to use in the Windows Charmap application.

https://docwiki.embarcadero.com/Libraries/Alexandria/en/Vcl.ComCtrls.TRichEdit https://docwiki.embarcadero.com/RADStudio/Alexandria/en/What's_New#TRichEdit_Component_updated_to_RichEdit_4.1_.28MSFTEDIT.dll.29 There are new events, e.g. OnLinkClick and extensions to the TTextAttribute type used by SelAttributes.

Oh come on, it's not that bad. There are even instructions on how to manually clean up after an uninstall in several blog posts on the emba site, e. g. https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwi8r9iV0un5AhVC7rsIHTWvAQ0QFnoECAQQAw&url=https%3A%2F%2Fblogs.embarcadero.com%2Fmanual-uninstall-of-rad-studio-delphi-c-builder-10-2%2F&usg=AOvVaw0wqOftotNG03B76ft4LoXa

Couldn't you just set the ScreenSnap property to true to allow the user to snap the form to a screen edge?

Are you setting up SelAttributes correctly before assigning text to SelText? D11.1 uses a newer version of the rich edit common control (4.x), which has more capabilities than the old 2.x version used by prior Delphi versions.

Looks like an attempt to hack a program to get around a security feature; you will get no help here for such (likely illegal) activity. It won't work anyway, if you modify a signed executable it will no longer match the signature and the OS will not load it.

Well, closing the main form ends up calling Application.Terminate, which results in a WM_QUIT message posted to the message loop. The reaction to that is to set Application.Terminated to true and fall out of the message loop in Application.Run. After that the Application object proceeds to free all forms and datamodules it ownes in the inverse order of creation. Things are unfortunately not always so clear, though. If a modal form is open it uses its own message loop, which also ends and causes ShowModal to return as if the user cancelled the dialog. Code in the calling method will execute after that until the code flow returns to the main message loop. A further complication are unowned forms. They will get destroyed after the owned forms when the main form window handle is destroyed, as far as I remember, by Windows, since the main form is the API-level owner of all secondary forms. Unowned Forms disconnected from the main form by overriding CreateParams will die last (unless explicitely closed in code executed when another form is destroyed), when the process dies. This usually does not give the form any chance to clean up after itself. So, if you need to have all forms die in an orderly manner you are best served by iterating over Screen.Forms and close each form found explicitely, with the main form last.

Whether this works or not depends on the source image format. TPngImage does not support direct assignment from a TJpegImage, for example. In such a case you have to go through a TBitmap as intermediate. procedure TForm1.Button1Click(Sender: TObject); var png: TPngImage; bmp: TBitmap; begin image1.Picture.LoadFromFile('C:\Users\Peter_2\Pictures\7.5. Stadtführung.jpg'); bmp:= TBitmap.Create; try bmp.Assign(Image1.Picture.Graphic); png:= TPngImage.Create; try png.Assign(bmp); png.SaveToFile('C:\Users\Peter_2\Pictures\test.png'); bmp.SaveToFile('C:\Users\Peter_2\Pictures\test.bmp'); finally png.Free; end; finally bmp.Free; end; ShowMessage('Done'); end;

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?