A.M. Hoornweg

Hello all,

my most important application, a big beast I've been working on for almost two decades and which I must maintain/support indefinitely, is an MDI application.  The program offers 50+ different views and editors and the users (working on oil rigs) usually have a handful of these MDI child windows open simultaneously.   The program can optionally run in SDI mode but nobody does that - it only clutters their desktop and they must have other applications (such as Word and Excel) open at the same time. A MDI window also has the advantage that you can quickly drag the whole thing (with all child windows) to a different monitor if it gets in the way.

It is currently built using Delphi XE.  I already had high-dpi awareness V2 working usably (don't ask - it took tons of hacks and sleepless nights) but since I expected native high-dpi support to come to Delphi some day, all those hacks can be automatically disabled with an IFDEF.

So now I'm trying to migrate this application from Delphi XE to Delphi Rio.  I can compile and run it successfully, but unfortunately Embarcadero chose to not support high-DPI in MDI applications and the visual result is really disappointing.  MDI child windows are now unusably small on a high-resolution monitor. I can't force the SDI application model through my users' throats so I must either get this DPI awareness to work properly on Rio or stick with Delphi XE.  

Sure I could write some flags into the Windows 10 registry to make the whole application non-DPI aware, but that's not a satisfactory solution. I had DPI-awareness working and now I'm losing that.

Any ideas on how to solve this?

3 hours ago, David Heffernan said:

This point about interop has merit, however, Boolean is the wrong type for interop. You need LongBool. 

In the Windows API, sure.

On 3/22/2020 at 7:07 AM, Joseph MItzen said:

UTF8 doesn't need a BOM regardless of encoding.

 

But a program (such as an editor) needs to know if the file is UTF8 in the first place. Without a BOM, it must guess.

On 3/21/2020 at 6:52 PM, David Heffernan said:

It's simple. Why write 

 

if SomeBool = True then 

 

when you can write 

 

If SomeBool then

 

It simply adds nothing. 

Not only that, but the code "if Somebool=True" has a little known pitfall.   

Every Delphi program interfaces with libraries written in C or C++ (such as the Windows API, all sorts of drivers etc) and in the C language, a bool is basically an INT.  I have had a few cases where a function was supposed to return a boolean and in reality it returned some integer where 0 signalled FALSE. 

The code (if Somebool Then...) treats 0 as false and all other values as TRUE.  That always works as intended.  The code "If Somebool=True THEN ..." only treats 1 as TRUE and everything else as FALSE. 

CASE statements are affected, too.

So the following code fails:

var SomeBool:boolean;
begin
   SomeBool:=Boolean(2); //Simulate a DLL returning a "wonky" boolean   
   if (SomeBool=True) then ShowMessage('True');
   CASE SomeBool of
     True: ShowMessage('True');
     False:ShowMessage('False');
   END;
   If Somebool then ShowMessage('Still it is true...');
end;

Hello all,

I'm in the process of evaluating if it's feasible to port a very large project from Delphi XE to RIO.

Now I'm stumbling upon the situation that the RIO IDE automatically inserts unit names (such as "system.actions") into forms I'm editing. 

That's a colossal p.i.t.a. since I need to be able to edit and compile these forms in Delphi XE as well.  I thought I could simply wrap these new unit names inside an {$ifdef compilerversion...}, but Rio will still append the unit names at the end of the unit list and then complains about the duplicate unit names. How can I prevent that from happening? 

Hello all, 

I'm experimenting with high-dpi in Delphi Rio 10.3.3 and I'd like to know what the best way is to make a tMainmenu having items with images.  The problem being that a 16x16 imagelist is unusably small on a high-dpi notebook screen.  The application still needs to support older Windows versions, so I can't use any stuff that's only available on Windows 10.  Any ideas?

The default calling convention in Delphi is "register" (the compiler tries to pass parameters in registers if possible to speed things up). 

The "Stdcall" convention is used throughout by the 32-bit Windows API (which consists of DLL's).  So, for consistency's sake, it makes sense to adopt that calling convention for your own 32-bit DLL's as well. "Stdcall" tells the compiler that the caller of the function will pass all parameters on the stack in a right-to-left sequence and that the function itself is responsible for cleaning up the stack before returning.

As Remy Lebeau pointed out, in 64-bit Windows there's only one calling convention. So you could do something like this:

//in the DLL:

Procedure MyProc; {$ifdef win32} Stdcall;{$endif} Export;

begin

..

end;

... exports 'MyProc';

//In the exe:

Procedure MyProc; {$ifdef win32} Stdcall;{$endif} external 'mydll.dll';

20 minutes ago, Cristian Peța said:

Don't use date as string in SQL filters. Pass dates as parameters. That calendar component should give you the date as TDate or something, not string.

Alternatively, if you already have a lot of code executing SQL statements as strings, just create a new tFormatsettings with the correct formats for date, time and decimalseparator for your database.  

Many Delphi string routines such as Format(), DateTimeToStr() etcetera have an optional Parameter of type tFormatsettings which will then apply this format.

I've been using HxD for at least 5 years, highly recommended.  

5 hours ago, Fr0sT.Brutal said:

Without BOM every file-handling utility is usable even that which knows nothing about UTF8. I had some shaman dances with XE2 and resource compiler trying to make them handle UTF8 properly and they all disliked BOM. Now 10.1 seems able to handle BOM UTF8 which is good but old habits remain for a while.

Could you give us a short explanation how to compile a UTF8 RC file containing unicode strings ?

1 hour ago, Fr0sT.Brutal said:

I just try to use UTF8 everywhere and get rid of all ANSIs completely

I prefer that, too. The matter is just if we should write a BOM or not.

In regular Windows INI files it won't work.

In tMemIniFile it will.

In XML it's optional.

In Linux it is frowned upon because everything is supposed to be UTF8.

In Windows every text is some flavor of ANSI unless it has a BOM.

23 hours ago, Fr0sT.Brutal said:

IMHO BOM causes more troubles than profit. I just remove it from every file I have

That's only safe if your character set is limited to Ascii.

Once it contains any character > #127, it is unclear which character it is, because how's the application to know the code page the file is using?  My code / annotations contain lots of umlauts and maths symbols.

It actually makes (some) sense. This latter setting enables Windows to ignore the high-dpi compatibility setting in the program's manifest so you can test out which setting works best for the application.  Also, you can specify if the setting is valid for all users or just for you.

In the current Windows 10 version, there's a new feature that lets you override the scaling behaviour of individual executables.

Right-click the executable in the explorer-> Compatibility -> Change High-DPI settings.

@alberto do you mean the Delphi IDE, or just apps compiled with 10.3.3  ?

@David HeffernanNice to hear we're in related businesess! I had no way of knowing.

Okay, so you're doing the documentation in external documents which you cross reference from the source.  I'm doing that too, but it's for lack of a better solution, because major changes/reformatting of the docs requires locating where the docs are referenced in the source and updating that, too.   It'd be sooo practical to have source and docs synchronized in the IDE somehow.  In full-screen mode I have 50% free space between the right gutter of the source code and the project explorer, it would be great to have a documentation tool fit in there that uses anchors/links in the source code.

Off topic: I find that the screen real estate of today's monitors is used inefficiently by most IDE's.  Ribbons at the top and logs at the bottom all reduce my view of the document I'm editing.  Recently I had to debug a large and poorly documented piece of source in Visual Studio so I decided to rotate the screen 90 degrees. That was... kind of overwhelming and very gratifying.  If my screens weren't so large I'd keep it that way.

Hello all,

I am sorely missing a way to document sourcecode alongside the sourcecode.

I believe that what I'm looking for doesn't even exist. Or?  I find formats like Xmldoc totally obnoxious because it interrupts the source code and the text is never in the place where I need to consult it.  My wide screen has plenty of horizontal space alongside the code.  So why can't I use that empty space to explain what my code is doing and why I wrote it that way, maybe even with nice text formatting, hyperlinks and images? 

Is your development machine a VM? Does it have the VMWare tools installed?

I find that it makes a *vast* speed difference in a VM when I disable unneccessary graphical goodies in Windows 10.

Go to control panel -> System-> Advanced system settings -> Tab "Advanced" -> Button "Performance Settings" -> Tab "Visual Effects" 

and click radiobutton "Adjust for best performance".

Then re-enable only essential stuff like "smooth edges of screen fonts" and "show windows while dragging".

On 1/15/2020 at 8:02 PM, Mark Williams said:

Has anyone had experience of the above (from https://www.cybelesoft.com/)?

 

I have just tried some of their live demos.  They do not work in my Opera browser but they do work with Edge. So depending on your browser, your mileage may vary.

23 hours ago, Mark Williams said:

 It needs to access several dlls and an ocx. The ocx is mine and could be (possibly should have been)  written as a dll. Are there any issues you know of with dlls?

An OCX  *is* a  DLL.

Currently "Consolas" and "Source Code Pro" are my favorites.

Hello all,

I would like to test a certain new monospaced font in Delphi but none of my Delphi versions displays it in the font drop-down list.  Is there anything I can do to use it anyway?

On 1/10/2020 at 6:33 PM, Stefan Glienke said:

 

Is the file ...

• available on other machines for the current user -> %appdata%\<program name>

Hi Stefan,

do you know if that folder is only for domain users? Or are there other scenarios in which that folder is synced between machines?

20 hours ago, Stefan Glienke said:

The refCount is -1 because its a reference to a string literal - UStrClr being called because passing to out does not deallocate but still put nil into the passed variable.

 

And fwiw the empty string also happens for WideString because then WStrClr is being called before passing as out. And while we are at it - yes AnsiString as well - LStrClr in that case.

Strange, when I first noticed the problem it went away 100% after I replaced string with widestring.  But somehow I can't reproduce that anymore. Weird!