A.M. Hoornweg

Can I call this structured diff viewer with command line arguments? I want to integrate it as an external diff viewer in tortoiseSVN ... Also, the menu item "help->user manual" does nothing...

"Event type=Bex" --> Buffer overflow exception. Most likely, the data written into a block of memory exceeds its size. There are tools to track down such errors (like Eurekalog, FastMM4 etc).

Hello all, does anyone else have the issue that a TImage containing a JPG does not re-size when the form is dragged to a screen with a different resolution? The weird thing: This only happens when the contained picture is a *.JPG. If the picture is a BMP or PNG then it *does* work OK. See attached image: The property "Stretch" is set to True in all 3 cases. (Edit) compiler version is Delphi 11.1 Alexandria.

OK, this is getting even weirder. I've placed a tTimer on the form plus an event handler to display the size of the 3 images. The size of the bitmap is 78x98 pixels in all 3 cases. procedure TForm25.check(img: timage; lbl: tlabel; fmt:String); begin lbl.Caption:=format('%s %d x %d',[fmt, img.Width, img.height]); end; procedure TForm25.Timer1Timer(Sender: TObject); begin check (image1,label1,'JPG'); check (image2,label2,'BMP'); check (image3,label3,'PNG'); end; Now look what happens if I drag the form to a high-resolution screen (250% zoom). The tImage having the JPG did not resize but claims to have done so anyway. The tImage with the BMP scaled correctly but still returns the unscaled size. And finally, the tImage with the PNG scaled correctly and returns the scaled size.

Hello all, this question isn't strictly Delphi related but rather Windows 11 / VMWare Workstation related. I develop under Windows 10 X64 in a VMWare virtual machine. I'd like to migrate this VM to Windows 11 but there are a few things that currently make this unfeasible IMHO: - before adding a virtual TPM module, VMWare insists on encrypting all virtual hard drives (*.vmdk files) of the VM. - The encryption key contains information of the host machine. The drives will only decrypt on the same host machine. - So if my notebook dies, I'm basically scr##ed because the VM won't run anywhere else. That's totally unacceptible to me. The whole purpose of virtualization is having virtual hardware so the VM's are independent of the host hardware and its life span. A backup of a VM shouldn't be worthless if my hardware breaks! I currently have VM's that were created on at least 3 different machines and they still run fine, thanks to a vmx entry uuid.action= "keep" that tells VMWare to maintain the machine identity even if the VM is moved to a different machine. So... What gives? Is there a viable workaround for this problem? I know about the undocumented managedvm.autoAddVTPM="software" vmx entry but let me warn you, that has dire side effects: instead of encrypting the vmdk files as a whole it will just encrypt the header area of the vmdk files. That is even worse because you can't undo it - the decryption password isn't revealed. And it's not documented if this header encryption is machine dependent or not.

Hello all, The delphi 11.1 VCL has some subtle internal changes in high-dpi behavior with respect to version 11.0. I would like to detect in code if the compiler in use is 11.1 or higher. Is there any possibility to do that?

No, "{assuming unicode string}" -> 1 char is 2 bytes so I'm actualy testing for 8. OP stated "Usually, the token is part of a larger string being parsed." So I assumed OP wanted to do a quick lookup in a token dictionary to figure out if there are any entries starting with that substring in the actual dictionary.

You could make the "key" in your tokendictionary a UInt64 instead of a string, but you'd also have to check that your strings have a minimum length of 8 bytes or else you'll get an access violation. Type pUint64=^Unit64; {assuming unicode string} if (fTokenLength >= 4) then if not fTokenDictionary.TryGetValue(pUint64(@Tokenstart)^,result) then ...

Yes, but the behavior might not be 100% identical because IIRC in DLL projects some things are not allowed in the initialization and finalization sections of units. But having said that, I usually test like this as well. A plain vanilla executable is the easiest to debug.

I believe it is, but there are simpler ways. IIS is not the only web server that can run ISAPI's. For debugging ISAPI's I personally use Aprelium's Abyss X2 web server. This can run as a normal executable and it comes in an x64 and x86 flavor. In the Delphi IDE I simply specify this program as the host process for my DLL.

Please specify more clearly what you're looking for. Something that sends print output to a file? PDF maybe?

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;

Duh. It looks like we got bitten by visual form inheritance. The tDatetimepicker is on a base tForm that is inherited from. This base form is perfectly OK but I see in an inherited DFM that "tDateTimePicker.Kind" is reverted to dtkDate. I can't explain how this happened.

That's very weird. My system behaves differently and so does a colleague's computer. The problem has been plaguing us for some time. I'll dig into this.

Simply reading property "datetime" fails in Alexandria if property "kind" is set to dtkDateTime. All manual changes in hh:mm:ss are completely ignored.

Maybe these servers were outsourced to a country now suddenly under embargo and Idera has been locked out ?

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?

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!

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.

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)

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?

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).

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;

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 ...