David Heffernan

1 hour ago, aehimself said:

Memo.Lines.LoadFromFile suffers from performance issues if the file is n x 10 MB, especially if it is on a network location. I changed most of my sensitive methods to use Streams instead:

  fs := TFileStream.Create('filename.txt', fmOpenRead + fmShareDenyNone);
  Try
   Memo.Lines.BeginUpdate;
   Memo.Lines.LoadFromStream(fs);
  Finally
   FreeAndNil(fs);
   Memo.Lines.EndUpdate;
  End;

 

This looks a bit bogus to my eyes. Why would this change anything. Surely LoadFromFile use a file stream. 

43 minutes ago, Remy Lebeau said:

Not in the IDE, no.  However, the DefFontData variable is publicly accessible, so you can modify it at runtime before creating any of your TForm objects.

I guess you could modify DefFontData in a design time package

No need for a workaround. Creating processes, and waiting for them to terminate is routine stuff on all platforms.

Definitely worth seconding everything that @Remy Lebeau said. You don't want to replicate ShellExecute because you don't want to use it at all. ShellExecute is used to execute shell verbs. But you want to create a process. A quite different thing altogether. Albeit the open verb on an executable file often results in a new process being created. 

There is no way to replace all the functionality of ShellExecute which encompasses the entire shell verb mechanism in Windows. 

What specific functionality of ShellExecute are you looking to replicate? 

@Stefan Glienke Your code above (and in spring4d) uses WriteProcessMemory to modify executable pages. This relies on an undocumented implementation detail of WriteProcessMemory. Namely that it will handle the protection flags on your behalf.  Personally I would prefer to use VirtualProtect with this sort of pattern:
 

procedure PatchCode(Address: Pointer; const NewCode; Size: Integer);
var
  OldProtect: DWORD;
begin
  if not VirtualProtect(Address, Size, PAGE_EXECUTE_READWRITE, OldProtect) then begin
    Fail;
  end;
  Move(NewCode, Address^, Size);
  FlushInstructionCache(GetCurrentProcess, nil, 0);
  if not VirtualProtect(Address, Size, OldProtect, @OldProtect) then begin
    Fail;
  end;
end;

You probably need to decide what you want to be secure from. As it stands it's probably impossible to give you specific advice. 

Class vars are global variables inside a type's name's pace. Class constructors are called from unit initialization. Class destructor from unit finalization. 

Firemonkey doesn't support right to left languages. Delphi is the wrong tool for you I am afraid. 

I don't follow that Stefan. 

41 minutes ago, Sonjli said:

 

Do you have any Pascal related documentation\manual about pointers?

Type delphi pointers into a search engine and start there. I'm sure there will be a mix of hits. Some better than others. Read the top 10, form a view on which are good and which are not. Reread the good ones. 

11 minutes ago, Cristian Peța said:

Maybe diving a little in assembler will help you to understand what is under the hood.

This has to be, in my opinion, one of the worst pieces of advice I have ever come across. 

1 hour ago, McScotty said:

My question was that I thought setting PopUpParent was the same (more or less) as setting WndParent in the CreateParams.

It is the same if you do it right. You didn't. Your code set the popup parent to be the application handle. But we were previously talking about making the main form the popup parent. You even had a potldt claiming to have done this but then your code told a different story. 

1 hour ago, McScotty said:

I really want to know why setting WndParent corrects a bug in the taskbar thumbnail that a standard Delphi application suffers from ordinarily if the dialog is not destroyed.

It doesn't. Setting WndParent doesn't fix your issue. It is setting WndParent to be the application handle that changes the behaviour. The reason that it changes the behaviour is that with application handle as popup parent then the dialog is not made visible when the main form is made visible. But, as I have explained before, if the application handle is the popup parent then the system won't guarantee that the dialog is always in front of the main form. 

I think I've said this a few times before, but I do believe that it's important to understand what popup parent does, and why it is important. My advice to you is to do some research on what popup parent actually is and why it is important to set it, with particular focus on modal dialogs. 

18 hours ago, McScotty said:

Yes sure.  Example 1 is the one with the issue on the taskbar, run the code and click on button then OK dialog.  hover mouse over taskbar and then the thumbnail image and you will see the closed (hidden) dialog is now visible, but will disappear again if you click on the thumbnail.

 

Example 2 is the same code, but the dialog has been modified to override the create process by adding Params.WndParent:=application.Handle;  Run the code as above and voila, no dialog is shown in the taskbar.

Example1.zip

Example2.zip

20 hours ago, McScotty said:

My understanding of the PopUpParent is that I can use it or I can use CreateParams and set the WndParent myself which results as the same thing.

 

If I set the PopUpParent to the main form it appears correctly, but still suffers from the showing the dialog in the thumbnail preview.

 

However if I use CreateParams and set 

 

Params.WndParent:=application.Mainform.Handle;

 

This does not suffer from the issue with the thumbnails.  Why is it behaving differently?

There seems to be some confusion.

You asked about why setting PopupParent to be the main form resulted in different behaviour from setting WndParent to the main form handle in CreateParams.

However, the two example projects you provided did not differ in that way.  In those projects the only difference is that one of them sets WndParent to be the application handle.  And you'd expect different behaviour in that case.

The API will be documented. It's essential that you use that documentation. 

On 10/26/2019 at 8:34 AM, Stefan Glienke said:

You only ever have to worry about dropping the TRttiContext when you unload modules such as dll and bpl during your application livetime from whom you needed rtti because then the type information from those modules is not removed and might still hang around possibly causing some issues.

You don't need to worry about even that because the dynamic memory associated with RTTI is ref counted and the refs will go to zero when the module is unloaded. 

Perhaps you could provide a minimal example of these two variants so we can see exactly what you are doing.

But when you make the application handle the popup parent, there's nothing to keep the modal form on top of the main form.

This conversation is going nowhere. You really do need to understand what popup parent is. 

You don't want to make the application window the popup parent. Then your dialog can appear behind the main form. You want the main form to be the popup parent. Which you can do in CreateParams, or by setting PopupParent.

It's important that you understand what popup parent aka Window owner in Windows terminology means. At the moment you seem to be trying stuff without understanding it. 

I think I already explained that destroying the window is the key to getting the behaviour you want. I gave you two options for doing that. 

I don't understand what you mean with these two handles. I guess you are talking about the popup parent. You can set this more easily with the VCL PopupParent property. The right thing to set it to is the main form. 

Do you understand what the popup parent is, aka window owner in Windows terminology? 

So I think that this behaviour happens because the window is not destroyed.  If you make the analagous WinForms app then you don't see this behaviour.  I believe that's because that framework destroys the window when the modal dialog is closed.

You can achieve the same thing by, guess what, destroying the form object.  That's really the best approach.  I can't stress strongly enough that's what you should do.

You could also achieve the same effect by forcing the window to be destroyed.  Call DestroyWindow on the modal form when it closes.  That forces windows recreation the next time you show it.  Perhaps that's safe to do.  I wouldn't do it.  I'd do it the right way.

Embarcadero are never going to "fix" this because it would require a complete redesign of the VCL.  Not going to happen.  

FWIW it is less nasty if you pass the main form as the owner of the dialog when you create it. You pass Application as the owner.

Actually, I'm not sure that's true having played around a bit more.

It's worth pointing out that this preview is drawn by the system. It's entirely plausible that there's nothing that Embarcadero could do to change the behaviour. 

OK. Carry on the way you are doing it, and accept the preview oddity. I'm just trying to describe how to avoid that. But maybe it's less important to you. 

So store the data in a collection and populate from that. Instant. And it's better not to use visual controls as data stores. They should just present views. Destroying the form when you close it solves your problem. And the performance issue is easily dealt with as I have described. 

1 hour ago, McScotty said:

The downside is simply speed.  If you have to fill a combobox with names for instance, doing this only once per application session is advantageous rather than destroying and having to fill the combo boxes again and again... 

Not so. Populating a combo takes no discernible time. Try measuring it.