Nigel Thomas

Not the answer you are looking for, but you are aware that many users these days have browser adblockers installed? I suspect depending on advertising revenue from website visits to support your application may not be the best way of funding your work on it.

Hi, For info (I realise it's still in Beta): I've downloaded the latest 8.66 from Subversion today. Installation on D10.1 was painless. Installation on D2007 ran into a couple of hiccups: 1) the runtime package requires VCLZipPack, which couldn't be found. 2) The RegisterComponents procedure in OverbyteIcsReg.pas tries to register the following missing components: TIcsTwitter, TIcsRestEmail, TIcsInetAlive. Commenting out these allowed the design package to be installed. Nigel

Hi Angus, Although this is a bump of an old topic, it appears to be pertinent once more.. I've downloaded the latest 8.70 (tried both SVN versions and the ics870.zip file) and attempted to install in D2007, after removing the older (8.68) version. Trying to build OverbyteIcsD2007Run fails with: Required package VCLZipPack not found. Nigel

if Trim(sTempFilesPath) <> '' then Trim *returns* the trimmed string, it doesn't trim it in place. Your code is still working on the non-trimmed sTempFilesPath.

What OS? D10.4.2 Community Edition runs fine for me here on Windows 7, Windows 10, and Windows 11. I don't recall having to jump through any hoops to get it working in Win7.

Hi All, Am I right in concluding that TRegistry.MoveKey fails to move REG_MULTI_SZ values correctly? In tests using D2007 and D10.4.2 (the code doesn't appear to have changed across those versions) such a move results in the creation of a value with REG_NONE and the strings from a MultiSZ value copied as raw binary data. I get why; DataTypeToRegData returns a TRegDataType and that type doesn't have a MultiSZ value. Given that RegQueryValueEx and RegSetValueEx do know about REG_MULTI_SZ, I'm guessing that MoveKey could be fixed to work correctly with MultiSZ registry values. I would however have thought that someone might have picked up this issue a long time ago, so I'm wondering if it's just me being dense. And if it's not me being dense, how to I go about fixing it given that I can't modify TRegistry?

Let's see if they at least fix REG_MULTI_SZ: RSP-39581

On my Insider Preview of Windows 11 22H2 (Build 22622.290) the batfile association, set in HKLM\Software\Classes, remains - as do all other expected file associations. I wouldn't have thought that would be something Microsoft would mess with as it would break so much stuff.

On 64Bit Windows, when a 32bit app calls a file-open dialog, e.g. TOpenDialog or TFileOpenDialog, then browses to the \Windows\System32 directory to select a file in that directory, the dialog actually displays the contents of the SysWow64 directory - even though the dialog title states it is browsing the system32 directory. I assume this is caused by file system redirection. I'd like to bypass it and browse - and select files from - the actual system32 directory. I've tried calling Wow64DisableWow64FsRedirection before creating the dialog but it has no effect. I expected to see at least a few posts about this on Google somewhere, but I've not come across any. Curious point: with the fileopen dialog open, it is possible to drag-and-drop a file from the dialog to the desktop - and the file that is dragged turns out to be the system32 file, and not the SysWow64 file (the filesizes of identically-named dlls are usually different so it is easy to confirm this). Whilst that is interesting, it doesn't help if one wishes to access a file that is in the system32 directory, but has no identically-named counterpart in the SysWow64 directory, as the dialog will not display it (confirmed by creating differently named files in each directory to see what was visible in the dialog). Edit to add: this behaviour is the same on D2007 and D10.4.2.

It's a Malware scanner. The select dialog is provided to allow the user to exclude specific folders/files from analysis. I suspect it will be rarely used to exclude system32/syswow64 files, and even less likely to land on a file that *is* in SysWow64 but is *not* duplicated in System32 (the only real time it makes a difference). The way the selection dialog lies about what folder you are viewing just irks me.

The dialog has no knowledge of sysnative. For 32Bit applications running on an x64 system, it displays the SysWow64 directory, it just tells you it is the System32 directory, Try browsing for a file or folder in System32 that does not have a duplicate-name in SysWow64 and you'll see the issue.

The string returned from the dialog contains "system32", so that is a non-starter. Besides which, the whole point of this query was to determine how to select files in the System32 directory that do not have duplicate-names in the SysWow64 directory. You can't, because you are only shown the contents of the SysWow64 directory.

The last time (Jan 2022) I requested a registration bump I was sent this: If you have not already, try emailing renewals with your request. They should assign it to Embarcadero EU, who should then contact you - try and get you to renew - then do the bump as requested. Or so I am told. I ended up not following through with my request as I copied the slip files from another machine, and renamed my machine to that machine (which I was retiring), and got my copies of D2007 and D10.1 working that way. This old SO question still applies, as far as I know: https://stackoverflow.com/questions/34451575/reinstalling-windows-without-re-registering-delphi

Thanks. I suspected that might be the case.

? Has a new CE edition been released and no-one has told us?

Like you did back in 2013 🙂 : SO 14647108 If statements were the answer for that scenario as well.

Hi all, My D10.4.2 Community Edition licence expired today. When I request a new licence from: Download the Free Delphi: Community Edition - Embarcadero I receive the following email: Subject: Thank You For Downloading Delphi 10.4.2 Sydney Community Edition Our records show that you have previously obtained a trial license for this product and version. A trial license can be issued only once. If you would like to extend the product evaluation, please contact Embarcadero Support at www.embarcadero.com/support. I seem to recall that this exact issue happened last year, when Embarcadero said it was a glitch. Looks like the glitch is still there? Nigel

Hi all, I emailed @Marco Cantu and he has replied promptly. They are aware of the issue with renewing CE licences and are working on a solution, although he says it may take some days to implement.

I tried using the Support link, but only received a vanilla response: Perhaps @Marco Cantucould get the right people informed?

Windows "Feature Updates" move Windows to Windows.old as part of the update process. I usually search in there for the missing files, and move them to the new Windows directory. I also keep a copy of the files elsewhere, just in case Microsoft loses them.. The files concerned are: Borland.Common.Targets Borland.Cpp.Targets Borland.Delphi.Targets Borland.Group.Targets And they need to be present (and therefore copied to, from Windows.old, or your stashed location) in: Windows\Microsoft.Net\Framework\v2.0.50727

I would also suggest reading "Delphi in a Unicode World" by Nick Hodges, it gives a lot of detail on how to change pre-D2009 code to D2009+. https://edn.embarcadero.com/article/38437

Unless you need to re-install, or install on a new system, and you've run out of activations 😞

"Ouch! - that bit!"

I doubt much has changed since this blog was written in 2018: https://www.microsoft.com/security/blog/2018/08/16/partnering-with-the-industry-to-minimize-false-positives/ " One of the most effective ways for developers to reduce the chances of their software being detected as malware is it to digitally sign files with a reputable certificate. "

As it is clearly a false positive, then yes. In my experience, MS have always been good at fixing false positive detections when I've sent them. Others might suggest uploading a copy to VirusTotal as well; I'd recommend against that, as it tends to just lead other AV vendors to jump on the bandwagon and add detection for a file they can see other(s) detect, but they don't, instead of actually analysing it.