David Heffernan

1 hour ago, santiago said:

Thx. for the info!

In case you have reported this, would you mind sharing the QC issue link(s)?

QC107411

But QC is dead. Or did it come back to life?

1 hour ago, santiago said:

One thing I have noticed in the Delphi Community is that older Delphi Versions are still heavily in use. For curiosity why do you still use XE7? Is it bugs preventing you from upgrading?

For me it is not money. I have later versions than XE7. For me there is no benefit to updating. Nothing released since XE7 has any significant benefit for me. For sure there are some minor things but nothing that really makes it worth the effort. 

And it is an effort for me because I have a whole bunch of patches that I apply to the RTL to address design flaws primarily in its handling of floating point. That requires bespoke code for each version and I don't currently think it is worth it.

Plus I'd have to spend some time working with multiple versions because I need to maintain recent releases of our software.

Now, if Emba did something about the very poor performance of the compiler code that dcc64 emits, I would upgrade without hesitation. 

In addition to constraining the window's size, you should consider giving the user visual feedback for their attempts to resize.

Do this by handling the WM_NCHITTEST message: https://docs.microsoft.com/en-gb/windows/win32/inputdev/wm-nchittest

type
  TForm1 = class(TForm)
  protected
    procedure WMNCHitTest(var Message: TWMNCHitTest); message WM_NCHITTEST;
  end;

....

procedure TForm1.WMNCHitTest(var Message: TWMNCHitTest);
begin
  inherited;
  case Message.Result of
  HTLEFT,HTRIGHT:
    Message.Result := HTCAPTION;
  HTTOPLEFT,HTTOPRIGHT:
    Message.Result := HTTOP;
  HTBOTTOMLEFT,HTBOTTOMRIGHT:
    Message.Result := HTBOTTOM;
  end;
end;

This is really excellent. It works a treat in XE7. Thank you.

I have one very minor suggestion. I wonder if it would be prudent to add a namespace to all your unit names to avoid potential clashes. For instance, one of your units is named Main and I bet there are other packages around that use that name. With a namespace prefix you sidestep any such pitfalls.

I can't believe that spring's DI container requires all interfaces to have lifetime controlled by reference counting. I suspect that you've been given a dud steer with all this reference counting code that you've added to your data module.

@Stefan Glienke would be in a better place to give guide you. He also might be able to compile this code where I can't because I guess I'm using a different version of spring from you.

Can't you make a minimal example? That's so important. I can't stress highly enough how important it is to make the example minimal. 

54 minutes ago, Mike Torrettinni said:

You think start /wait project1.exe is not best solution for my problem? Better suggestion?

No. It's exactly what I said. You have to wait for the process to terminate. I was commenting that your explanation was wide of the mark. 

1 hour ago, Mike Torrettinni said:

Right?

Not really. If you want the exit code you need to wait for the process to terminate. The exit code is only available after the exit. 

A GUI app doesn't attach to the console at all so it's about the consoles that are involved. 

2 hours ago, Remy Lebeau said:

In general, const applies to the thing on its left, unless there is nothing there then it applies to the thing on its right instead.

Is that is a little bit loose? Consider

2 hours ago, Remy Lebeau said:

void FreeAndNil(const TObject* const &Obj);

The second const binds to what exactly? Not "the thing on its left".

2 hours ago, Dalija Prasnikar said:

For stuffing in pointers and such... it is not appropriate, but for storing integer values that can later be used to determine appropriate action... why would that be wrong or used only in toy apps?

 

In Delphi I never used Tag in toy apps knocked up in minutes, because they were pretty simple, but in more complex ones, especially with dynamic content and multiple entry points for actions, tag is the most straight forward thing to use and maintain.

 

Also, just yesterday, I wrote a whole a lot of tag based code in native Xcode iOS application where native view also has tag property specifically used for determining which action you want to run. And there just like in Delphi you have Sender object that you can also use to determine appropriate action, but just like in Delphi code working with objects would be more convoluted and using Tag is preferred when you have to determine or change action at runtime.

 

 

I'd far sooner use Sender in an event handler to identify the control, and then have a map to anything else.  Tag falls over as soon as you need to handle more than a single aspect.  Plus there is no type safety.

I have never understood why Tag would ever be used. I mean I get it for a toy program knocked up in a couple of minutes. But not for real world code. 

I'm sure you know how to work with list objects, and how to set the Visible property. 

1 hour ago, PeterPanettone said:

If you have several panels then the handling becomes expensive.

It's not at all difficult. Put them in a collection and hide all of them apart from the active one.

Has the benefit of doing exactly what you want. 

It would be far simpler to remove the page control and tabsheet and have the panel placed directly on the form.

16 minutes ago, Mike Torrettinni said:

Do you have a real case scenario for using the second option, TSessionID = type integer; ?

For integer, due to assignment compatibility rules of the language, the only use is to provide a distinct type identity to be used in RTTI settings. For instance if you wanted to have a separate design time property editor for this type.

Distinct types don't give you type safety when used with integers and strings. These distinct types are still assignment compatible. There is a use in type identity for design time  property editors. 

If you want type safety for assignment you'd need to wrap in a record. 

All this speculation..... A minimal example and the answer would be simple. 

3 hours ago, Mahdi Safsafi said:

I wish if you were right ... but things are much much more complex than that. E.g : sometimes there is an official mechanism but you choose message instead because you don't want the official mechanism to perform a paint for example ... there is a lot of those examples.

I also talked about such examples. This isn't one of them. 

3 hours ago, Mahdi Safsafi said:

I didn't take any dependency (please read my example again) !

You said, "I'd understand if the logic was implemented in RecreateWnd but that's not the case here". You literally talk about making a choice based on the implementation details.

I still can't see why you are set against calling RecreateWnd. That seems perverse to me. 

3 hours ago, Mahdi Safsafi said:

FYI, there is no concept of private/protected for messages. Messages are public !

Not so. For sure the language doesn't stop you using any message you like. But that doesn't mean that it is reasonable to do so. Oftentimes messages are used in the private implementation detail for a class.  As a broad principle, you should not be looking to work with Windows messages when consuming VCL controls.  Sometimes one is forced into it because the control provides no official mechanism.  But when we do that, it is brittle, and subject to future implementation detail changes.

3 hours ago, Mahdi Safsafi said:

I'd understand if the logic was implemented in RecreateWnd but that's not the case here !

And there it is.  There's the point where you take a dependency on on implementation details.

The implementation of RecreateWnd is:

procedure TWinControl.RecreateWnd;
begin
  if WindowHandle <> 0 then Perform(CM_RECREATEWND, 0, 0);
end;

There is a difference between this code and yours. Your code does something unconditionally. But RecreateWnd does nothing if the window handle has not already been created.

I'm quite sure that you've got this wrong.  I mean, it won't have any material impact on things, but one may as well do things the right way.

6 hours ago, Mahdi Safsafi said:

For Main form that's not necessary. RecreateWnd is useful when creating dynamic controls as you don't know when there would be the handle available.

This doesn't make sense to me. I don't see the argument for sending a private implementation specific message rather than calling the RecreateWnd method. 

Dude, just make a minimal example and debug that. Post it here if you want. Really good discipline to learn how to make that minimal example. 

Cut this code down to the minimum that leaks. Then debug that. 

Try finslly still wrong. You must acquire the resource immediately before the try

Foo := TMyObject.Create;

try

  Foo.Use;

finally 

  Foo.Free;

end;

As you have it, if an exception is raised before the variable is assigned, you'll call Free on an uninitialized variable. 

Not the cause of the leak, but each of those calls to TSomeObject.Create needs to be protected in a try/finally

Free is implemented as if Assigned(Foo) then Foo.Destroy; so those if statements in the previous post are pointless. Call Free unconditionally.