Stregor

Hi guys,

My old Code Signing certificate (trusted by Smart Screen) was expired. I bought the new one (from Comodo/Sectigo), and with it i bought a problems with Windows Smart Screen. In Win10 and in Edge browser my customers see, that my software installer is a risky and can potentially damage computer. Discourage :(

My company has no many customers. So rebuild trust will take a lot of time.

Is a way to speed up that process? Submit a file for malware analysis - Microsoft Security Intelligence is a correct way or maybe exists different, better way?

Hello Uwe.

I was tested 15.x a moment ago, and:

Ctrl+E when i edit entire class TFoo - about 50 sec with "Check Packages" checked (seems no matter first or next use, but i did not measure it with a stopwatch)

Ctrl+E when i edit entire class TFoo - about 1 sec with "Check Packages" unchecked

14.x

Ctrl+E when i edit entire class TFoo - First use - 14 sec,  second and next uses - 4-6 sec with "Check Packages" checked

Ctrl+E when i edit entire class TFoo - about 1 sec with "Check Packages" unchecked

Hello.

I'm using Rio 10.3.2 and newest MMX 15.x. My project is quite big - about 350 .dfm and about 700 .pas

I observe dramatically reduced speed of using "Open Unit" dialog (Ctrl+F12) and "Edit Entity" (Ctrl+E). From click Ctrl+E to show dialog - especially when i want edit entire class or interface, not class member - sometime i must wait a minutes! Yesterday for about 35 minutes of waiting i must kill Delphi. 

First i blamed Rio, but when i uninstall MMX 15 and go back to MMX 14.x then speed return to normal. Still not lighting speed but acceptable :)

P.S. in Delphi Seattle is the same problem with MMX speed.

On 3/19/2019 at 3:19 PM, PeterBelow said:

Why are you rebuilding 3rd-party dcus as part of your build process? IMO only the (prebuild) DCUs should be on the IDE library path, the source code folders should only be on the IDE search path and not on the project's search path.

On 3/19/2019 at 8:22 PM, Stefan Glienke said:

That's why Peter said prebuild - you do that once (and whenever you need to fix some of 3rd party code which is compared to your own code rather rare talking from experience) and then use the produced dcus. That way you only get compiler messages from your code without being mixed with any 3rd party noise.

 

If you work on a large enough application with enough developers that produce builds nonstop rebuilding the same unchanged source code every time is an issue. Especially when Delphi decided that it does not like the "compile" option for whatever reasons and forces you to do "build"

I have problem with that.

I create small test project, one form with one visual component. Visual component is a part of, for example, devex library.

I want to not recompile devex every time I must build project, so:

1) I build my project once,

2) I copied devex .dcu from project output dir to a separate directory (for example "builded_dcu")

3) I remove path to devex source files from Library path and put it to Browse path

4) I put path to "builded_dcu" folder to Delphi Library path.

And...

If I compile, it's work. Delphi use ""builded_dcu" as source of Devex .dcu, compile only my own code, everything is ok. But when I build my project, Delphi want access to .dfm and .res files from Devex source.

What i do wrong?

I must build my own code, because i use simultaneously 2 or more build configurations with different conditional defines with my own code.

Workaround will be put in Library path first path to "builded_dcu", then path to Devex source, but when I build, I build all, my own code and Devex code. I must copy every single .dfm and .res from Devex to "builded_dcu" folder? Or is a other way, and I do some terrible mistake?

Marco write:

Quote

Initializing Inline Variables

A significant change compared to the old model, is that the inline declaration and initialization of a variable can be done in a single statement. This makes things more readable and smoother compared to initializing several variables at the beginning of a function.

procedure Test; // declaration and initialization in a single statement
begin
  var I: Integer := 22;
  ShowMessage (I.ToString);
end;

Why not go one step further and allow initializing local variables?

IMHO will be nice to type:

procedure Test;
var
  lLastName: string := 'Type last name here';
begin
  lLastName := InputLastNameThere(lLastName);
end;

Of course, this will be a syntactic sugar, because compiler must add  lLastName := 'Type last name here'; at the first line after begin