Jump to content

A.M. Hoornweg

Members
 View Profile  See their activity

  • Content Count

    507

  • Joined

  • Last visited

  • Days Won

    9

Posts posted by A.M. Hoornweg

  1. Posted

    OK, this took me some time to figure out, but it is actually possible:

     

    - Put a tDateTimePicker on your form

    - Set property "Kind" to "dtkDateTime"

    - Set property "Format" to "dd/MM/yyyy HH:mm:ss"       (the capitalization of MM and HH is important!)

     

    -Setting the tDateTime is easy, just use property datetime.

    -Use the following routine to GET the tDatetime.

      

    Function ExtractDateTime(Picker:tDateTimePicker) :tDatetime;
var buf:pWideChar; LastBlank,i,len:integer;
    Text,TimePart:string;
begin
     len:=picker.GetTextLen+1;
     buf:=Stralloc(len);
     picker.GetTextBuf(buf,len);
     Text:=buf;
     strdispose(buf);

     LastBlank:=length(Text);
     for i:=length(Text) downto 1 do
     begin
       if Text[i]=' ' then
       begin
         LastBlank:=i;
         break;
       end;
     end;

     TimePart:=Copy(Text, LastBlank+1, length(Text));
     result:=picker.Date+strtotime(TimePart);
end;

     

     

     

     

     

  3. Posted

    15 hours ago, jeroenp said:

    This is true: some of the time it is up.

     

    Over the last 24 hours downtime is "more" than 55% (not the kind of SLA I would be satisfied with, but hey: I'm not Embarcadero IT), see the saved status at https://archive.ph/2HXRI:

    From the history on that page (or browsing the live status at https://stats.uptimerobot.com/3yP3quwNW/780058619), you can see that both uptime and downtime periods vary widely between roughly 5 and 90 minutes.

    To me that sounds like intermittently failing or underdimensioned hardware.

     

     

     

    No it is not.

     

    Guys, just take a look at the PHP exception trace.  More specifically, the line that reads  "LoadBalancer->getConnection(0,Array,false)", that's where the shit hits the fan.

     

    That line triggers a "connection refused" exception. One of the servers which the load balancer can choose from in this array is inaccessible. 

    Not all of them are inaccessible because when you press F5 often enough in your browser the load balancer will sooner or later hit one that works. 

     

    So this is a simple web site management issue.  The person in charge should simply remove broken db servers from the list which the load balancer uses to choose from.

     

     

    So... Why the heck does Idera not manage this properly?  

     

     

     

     

     

     

     

     

     

    loadbalancer.png

    • Like 2
    • Thanks 1

  4. Posted

    11 minutes ago, Lajos Juhász said:

    We that already using Delphi should know to work without a proper documentation.

    I was hoping to save some time by finding out if an existing class is suitable for my needs. More specifically, I wanted to know if tStringbuilder has functionality to use it as a fifo buffer.  

  5. Posted · Edited by A.M. Hoornweg

    11 minutes ago, Lajos Juhász said:

    There is no need to panic. It's out for about 2 two weeks. There was a recent webinar from Ranorex that modern IT companies now have a monthly schedule for release. So before we all panic we have just to wait another 2 weeks and see whenever that time frame is used in Idera or not.

    Breaking a production system in the process of releasing something is simply not done. One first gets the new system ready, only then is the old one taken offline. A two weeks outage is dramatic with respect to the perceived reliability of a company.

     

    (edit - typo)

  6. Posted

    How long has it been now that the docwiki is dysfunctional, one week? Two? 

     

    The site will only work once in five attempts or so, all the other attempts show an error log saying the database backend can't be reached.  There's some kind of load balancer in front that doesn't know which of the servers behind it is actually working and which is not....   The end result is like Russian Roulette ! 

     

    @Embarcadero: Guys, this is how not to do load balancing. At least make sure your load balancer knows which servers actually work!

     

     

  7. Posted

    26 minutes ago, Uwe Raabe said:

    That is quite some valuable information. 👍

    Thanks.  I have stumbled upon a ton of bugs in dpi-awareness so far but I haven't had the time yet to report them to QC because that usually requires test cases.   

     

    Another subtle one: If you use tScrollbox, you need to set tScrollbox.Vertscrollbar.Position to zero before a DPI change, otherwise some components on the tScrollbox may become unreachable after the scaling (the ones near the top). 

  8. Posted

    I'll see if I can concoct an example next week. It's hard to extract from my current program. I can tell you that it definitely happens in some forms of mine that have some panels with constraints and other panels with align=alClient, it causes these forms to "explode" when they are dragged between monitors. 

     

    By trial and error I could stop it from happening by protecting WMDPICHANGED against recursions. 

      

    procedure tMyForm.WMDPIChanged(var Msg: TWMDpi);
begin
  inc(fChangingDPI);
  try
    if fChangingDPI = 1
    then
      inherited    
    else
      Msg.Result := 0;
  finally
    dec(fChangingDPI);
  end;  
end;

     

  9. Posted

    One observation: 

     

    in unit Vcl.Forms there's an optimization in tCustomForm.WMDPICHanged which ensures that a form is only re-scaled when Message.YDPI is unequal to fCurrentPPI.

     

    Assuming that fCurrentPPI may not be perfectly reliable, I have removed that optimization just for testing.  And bingo, my form now appears to re-scale properly every time.

      

        //unit vcl.forms.pas method tCustomForm.WMDPICHANGED
    
    if (* (Message.YDpi <> fCurrentppi) *) and Scaled then
    begin
      DoBeforeMonitorDpiChanged(fCurrentppi, Message.YDpi);
      OldPPI := fCurrentppi;
      ScaleForPPIRect(Message.YDpi, Message.ScaledRect);
      FCurrentPPI := Message.YDpi;
      fPixelsPerInch := FCurrentPPI;
      DoAfterMonitorDpiChanged(OldPPI, FCurrentPPI);
    end;

     

     

     

    Also I've found out that constraints may be problematic in Delphi.

     

    Normally, when a form is dragged to a new monitor having a different scaling factor and its center reaches the new monitor, Windows sends a wm_dpichanged message to the window's wndproc to inform it of the new resolution and also gives it a pointer to a rectangle containing a proposed new position and size. The form must then redraw itself using the proposed position and size to ensure that  the scaled window is definitely on that new monitor.

     

    However, constraints in VCL components can enforce size limits to components and to the form itself.  So it may very well be that after the positioning and resizing, the center of the form is suddenly back on the previous monitor ...

     

     

    • Like 1

  10. Posted

    Hello World,

     

    I'm trying to debug some dpi-awareness problems in an application of mine (using Delphi 11 on a Windows 10 X64 VM).  I have a 3-screen setup with different scaling factors for testing (from left to right: 300%, 100% and 175%). I test dpi awareness by dragging my main form between these screens. 

     

    Most of the time the re-scaling kinda works (albeit slow), but sometimes things get wonky and I wanted to know why. This main form of mine is a rather complex one and it needs some time to redraw when the screen DPI changes. I'm trying to reduce that amount of time but in this case the VCL components themselves are kinda sluggish.

     

    For diagnostic purposes I have overridden the method tForm.DoAfterMonitorDpiChanged() to output some debugging information and the outcome puzzles me.

      

    procedure tMyForm.DoAfterMonitorDpiChanged(OldDPI, NewDPI: Integer);
begin
  inherited;
  OutputDebugString(Pchar(Format('Currentppi / Pixelsperinch  %d / %d',[currentppi, pixelsperinch])));
end;

    Most of the time the values of CurrentPPI and PixelsPerInch are identical and reflect the value of the screen where the form was dragged to, but occasionally they go out of sync. 

     

    When that happens, one of the two contains the DPI of the new screen where I moved the form, whilst the other one reflects the dpi of the screen where the form used to be. This happens especially if the dragging was "fast".

    When I look into the source code of unit vcl.forms, I see that the developer usually sets both properties to the same value. So I assume this behaviour to be a bug. Also, I fail to understand why tForm needs both these properties if they are intended to always be the same value. Unfortunately I can't consult the on-line help because https://docwiki.embarcadero.com has been down since yesterday.  Can anyone shed some light to this, and maybe try to reproduce the behavior?

     

     

     

     

    dpi out of sync.png

  13. Posted

    Hello all,

     

    I have a tImagecollection with square transparent PNG images at 256x256 size which I want to downscale smoothly. The collection's interpolation mode is set to icIMModeHighQualityCubic.

     

    I notice that tVirtualImage gives much smoother image quality at 32x32 than tImage if I manually downscale the image using tImageCollection.GetBitmap().   

     

    I would very much like to get to the bottom of this.

    This is the code I use to manually extract and downscale an image from tImagecollection.

    Parameter "Targetimage" is just a TImage on some TPanel on a TForm. Am I doing something wrong?

     

      

    procedure LoadImageFromCollection(TargetImage: tImage; ImageName: string; Collection: TImageCollection;
  DesiredHeight: Integer);
var
  tb: tbitmap;
  h,idx: Integer;
begin
  idx := Collection.GetIndexByName(ImageName);
  if idx > -1 then
  begin
    h:=desiredHeight;
    if TargetImage.AlignWithMargins then
      h := h - TargetImage.Margins.Top - TargetImage.Margins.Bottom;
    TargetImage.Height := h;
    TargetImage.width := h;
    TargetImage.Transparent := True;
    tb := Collection.getbitmap(idx, h, h);
    try
      tb.AlphaFormat := afDefined;
      TargetImage.Picture.Bitmap.Assign(tb);
    finally
      tb.free;
    end;
  end;
end;

     

     

  15. Posted

    3 hours ago, David Heffernan said:

    Not if the comctl v6 manifest hasn't been activated in your thread. You'll have comctl v5.8.

     

    You need to activate the comctl v6 manifest whenever your DLL is called and deactivate whenever it returns. Every function should activate on entry, deactivate on exit. 

     

    I do this in my Excel com add in. 

     

    Oww, that sounds like a pain.   But I think it should be possible to just pack a manifest alongside an existing application, without embedding it and damaging the digital signature?

  16. Posted · Edited by A.M. Hoornweg

    9 minutes ago, Lajos Juhász said:

    You mean this reference at https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Controls.TImageList:

    Note: Image lists depend on Comctl32.dll. If the system does not have the latest version installed, there may be problems getting images to appear.

    The problem isn't tImageList related - the DLL used tImageList in the past without problems or manifest requirements until I replaced it with tImageCollection & tVirtualImageList.

     

    Also, the operating system is Windows 10, so comctl32 on the system is most certainly the current version.  By the way, with a properly manifested application, the new icons display correctly even on Windows XP which is vintage so I don't think it's a matter of an outdated comctl32.

     

    ( edit: I compiled the test application under Delphi 11 fixpack 1 with {$SETPEOSVERSION 5.1} {$SETPESUBSYSVERSION 5.1} to make it work on XP).

  17. Posted

    Hello all,

     

    I am using tImageCollection and tVirtualImageList inside a COM DLL to display some images on buttons etc.  This COM DLL is an update to an existing version - the calling processes are existing programs, many of which were compiled with older Delphi versions.

     

    I'm observing a very strange phenomenon: the images on the buttons in the DLL are not displayed if the calling executable does not have a manifest.  They are only displayed if the calling executable has a manifest. I find no reference in the Delphi documentation that tImageCollection has manifest requirements.

     

    Can anyone shed some light on this?

     

    My reason for asking: I cannot update the existing legacy applications with a new manifest - they are digitally signed and inserting a new manifest would break the signature.. 

  19. Posted

    4 minutes ago, emileverh said:

    I agree. DPI awareness in Delphi 11 is a mess!!  People who are telling; you have to develop in 96dpi mode do not own a high-end PC with a high resolution screen. The forms are incredible small in that way, it's impossible to design a form. And frames are the worst part....

    One simple workaround is to run Delphi inside a VMWare VM and to configure that VM so, that its resolution is 1920x1080 and "stretched".  That way Delphi will run at a resolution of 2K even though the monitor really has a much higher resolution.

     

     

    As for DPI awareness in compiled Delphi applications themselves, I have a whole bunch of workarounds to make things work better. The key for me was to inherit every TForm from a common ancestor and to override some virtual methods in that ancestor  (DoBeforeMonitorDPIChanged, DoAfterMonitorDPIChanged, Loaded, Docreate and some more ...)  to fix the most egregious bugs.  That way any form derived from that common ancestor behaves much better.

     

     

     

     

     

     

     

     

     

  21. Posted

    1 hour ago, Sherlock said:

    Well cancel Windows 11 then. No need for it anyway. Only for testing. Some folks still use WinXP, being stuck on Win10 till MS comes to their senses seems not that long.

    Some things (like Per-Monitor DPI-awareness V2) are really awkward to test through Remote Debugging.  Delphi 11 still has tons of issues regarding DPI Awareness, for which I had to devise workarounds until Embarcadero hopefully gets it right. I expect some improvements to this feature in Windows 11 and it would be really nice to be able to debug it natively rather than remotely.

     

     

  25. Posted · Edited by A.M. Hoornweg

    14 minutes ago, Attila Kovacs said:

    With your logic not only the VM but an encrypted HDD would not be recoverable anymore.

    A virtual HDD encrypted by VMWare would not be recoverable anymore indeed.

     

    [edit]

    I make weekly backups of my VM's on an external HDD. If they were cryptographically tied to my notebook's hardware, they would become worthless if my notebook broke.

×