Adam

That used to work for me, but I started having complications the last couple of years. There's a few other support requests at DevEx regarding it, but in the end it was just 'unsupported'. Now that I've got things that appear to be working - I'm not game to make any changes incase I break it and can't get it working again, so will leave things as they are for now, but thanks for the heads up. I think in Delphi 12, the packages are named with 290 at the end of them. (At least from my memory from last week when I was deleting the BPL's), so that might have changed now? With prior versions of Delphi I think Embarcardero omitted the version number suffix. (Although again, I'm going from memory now, so take with a grain of salt).

I had to disable the LivePreview package, along with some DevEx packages, such as SchedulerWebServiceStorage, CloudServiceLibrary, MapControl, and a few others. I'm pretty sure this (especially the livepreview) comes down to dcu/bpl's being compiled with a different version of <indyunit> than what is now currently installed. In DevEx's case, it comes down to procedure entry points not being able to be located. I get what you're saying - with DevEx it should (and does) recompile the units when it installs. For some reason these last few don't seem to work. (Possibly not all the source code is included for those, I don't know?) It's been unfortunate but over the last couple of Delphi versions I've given up on being able to have both. DevEx won't support any Indy installs except for the one packaged with Delphi when it ships. Since my apps require what's in the SASL-oAuth branches, I have no options except to either ditch using these incompatible packages, or to ditch Indy. So far I've been able to avoid those other components and stay with Indy, but it's getting harder, since components that use Indy don't support patching Indy to the latest version, and from what I can tell, Embarcadero doesn't include Indy updates with their patch updates. (Although even if they did - in this case with sasl-oauth not being merged in, it wouldn't make a difference at this point anyway). I have no idea how you managed to replace indy totally without losing (at least) the livepreview that comes with Delphi. (I'd hate to guess how many weeks in total over the past couple of years I've spent trying to get this to work over the past few Delphi installs I've done)., and have never been able to achieve what you have. (Plus, according to Remy it seems like he's suprirsed you could do it too)? For now - I have what I need - the updated installed and the ability to update DevEx (as long as those other packages aren't needed). Thanks to everyone who's helped and taken the time out to reply. Who knows... maybe the next version of Delphi will be my lucky build where the included Indy components contain all I need and I don't need to go through this again, and 13 will be my lucky number. 😁

OK - an update. I was unfortunately not able to get Indy to work just by including the changed units that I needed for oAuth. It seems that the changes go deep right back to the idpop3 unit, which is pretty much integrated throughout a lot of Indy. What I did manage to do however was uninstall and remove Delphi's Indy, and replaced with the latest Indy, and get DevEx installed afterwards. It requires having access to DevEx path in the library for builds so that it rebuilds the units relating to Indy. Some components had to be dropped - but I think this will get me out of trouble, and hopefully allow me to keep updating DevEx on Windows 12 moving into the future. It would be good though to have SASL-oAuth officially distributed by Embarcadero in their future releases of Delphi. That would allow me to use all the components accordingly. I think the idea of just using individual indy units for what has changed would work well for minor changes, and possibly bug fixes, but unfortunately the SASL being so involved appears as though it's not a possibility in this instance. Thank you to everyone who has kindly taken the time out of your day to reply and assist me with all this! Adam.

Hi Remy, Thanks for updating that branch so promptly. That's greatly appreciated. I will update it my end. Hmm... if I can do that, this would be definitely the best way to go. I'm not sure whether the SASL components are compatible with the version that comes with Delphi (if additional parameters are required or not). If I could just add the OAUTH/SASL, and leave everything else alone - that may allow me to keep all the existing components that are normally removed when updating Delphi, along with being able to do DevEx updates in the future - which would be ideal! Thanks for the suggestion!

Thanks Shineworld, Nifty way to do it. At present I'm suspicious that part of my issue is that the branch I have hasn't been upgraded to work with Delphi 12 yet. I could be wrong, just waiting on confirmation first.

Looks like trying to install it seperately is failing too. I'm hitting the same problem again with ambiguous overloaded call to LocaleCharsFromUnicode, so I'm thinking the SASL branch may not be XE12 compatible. @Remy Lebeau - are you able to advise please whether or not the SASL-OAuth branch at https://github.com/IndySockets/Indy/tree/sasl-oauth is compatible with Delphi XE14 at this time? I'm only seeing up to Indy280.groupproj, and I believe Delphi 12 should be Indy290? Thanks & Regards Adam.

Hi Shineworld, Thanks so much for that suggestion. It's very encouraging to hear that this is possible. This would allow me to continue to perform DevEx updates as they come through, as well as use other components in other projects I don't have Indy, but also utilise indy and not have to switch to a different set of mail components! I've given this a try. Just adding the indy10 directory didn't work for me. I was getting errors such as undeclared identifier TIdSASLXOAuth2 (which is a component in the branch I wish to use, but not available in the original install). I then tried adding the paths to Protocols, Core and System, it compiles past this point, however I end up with a compile error of "Ambiguous overloaded call to LocaleCharsFromUnicode'" in idglobal.pas. I was just wondering if you encountered that when you first started out and if you know what the solution might be? I've added the Protocols, Core and System paths to the projects compiler search path, but just wondering if I'm missing a directory or step? Like you, Thanks & Regards Adam. Edit: Please disregard. I managed to get this to work by prefixing the calls with "idGlobal." to specify to use the function contained in it's own unit. I'm now also going through this in a few other places, as well as getting rid of some IFDEFS and forcing the code for my version of Delphi to try and get it to compile. I'm guessing there's some conditional defines that work themselves out automatically if I was to compile the dpk's but of course that's what we're bypassing to have a dual install. My application now compiles, but the indy components don't seem to be have (just seem to do nothing after they attempt to connect, so I might be stuck with having to uninstall the Delphi ones, and commit to this build and not be able to get any future DevEx updates unless I completely reinstall the IDE each time).

Hi Remy, Thanks for the clarification. I misread that in that there could be 2 consecutive installs of Indy. Thanks for clarifying. Best Regards Adam.

Hi Remy. Thanks for the clarification. I guess it's a spelling mistake on the Github website. "Can" probably was supposed to be typed in as "Can't"? ;) On a separate note, do you know if the sasl-oauth branch will be merged prior to the next Delphi release? This is the only reason I need to custom update indy, and it unfortunately restricts what other components I can use, and completely breaks my ability to install DevExpress updates once I do it. Best Regards Adam.

Hi, I'm building my XE 12 development environment. Previously, I have just uninstalled Indy (that's packaged with the Delphi installer), and installed Indy separately. However I ran into issues with incompatibilities with Indy and DevEx. (All would work OK, but I could never install an updated version of DevEx without errors afterwards). I noticed on the notes listed on https://github.com/IndySockets/Indy/wiki/Updating-Indy#important-notes that LivePreview/EMSEdge will also be unavailable if I do the update, however the website goes on to say "You can use a separate installation of Indy 10 for non-LivePreview/EMSEdge projects. This has not been addressed by Embarcadero yet so Indy 10 upgrades and LivePreview/EMSEdge can co-exist." However, I haven't been able to find any information on how I can have the two versions to co-exist. (My hope was to use the latest version to compile my Delphi projects, which require TIdSASLXOAuth2 which unfortunately doesn't appear to be available yet in the packaged version that ships with Delphi XE12. Can anyone please point me in the direction of how to have both installed within the same IDE? Thanks Adam

Thanks all for your replies. I have no idea. I've been with Delphi since v1. I guess every now and then the brain does something funny and brings back something that I did years ago as though it's still applicable. I appreciate the clarification. Thanks all!

Yet no mention of that in the help files. Thanks for pointing that out. What's safe to use then Just n := v?

Hi, Just wondering if anyone can please tell me what I'm doing wrong here. Calling VarToInt64 brings up an access violation: var v : Variant; N : Int64; VMGR : TVariantManager; begin v := 1234567890; N := VMGR.VarToInt64(v); end; Thanks & Regards Adam

Not the most elegant solution - but it will at least get you started: var Mi: TMenuItem; Mx: TMenuItem; begin tbl.open; tbl.First; while not tbl.eof do begin if tblIDParent.value = 2 then begin Mi := TMenuItem.create(MainMenu1); Mi.Caption := tblName.value; Mi.Tag := tblID.value; MainMenu1.Items.add(Mi); end; if tblIDParent.value = 3 then for var i := 0 to MainMenu1.items.count - 1 do if MainMenu1.items[i] is TMenuItem then if TMenuItem(MainMenu1.items[i]).tag = tblIDParent.value then begin MI := TMenuItem.create(TMenuItem(MainMenu1.items[i])); MI.Caption := tblName.value; MI.Tag := tblID.value; TMenuItem(MainMenu1.items[i]).Add(mi); Mx := TMenuItem.create(TMenuItem(MainMenu1.items[i])); Mx.Caption := 'ADD'; Mx.Tag := tblID.value; Mi.Add(mx); Mx := TMenuItem.create(TMenuItem(MainMenu1.items[i])); Mx.Caption := 'DEL'; Mx.Tag := tblID.value; Mi.Add(mx); end; tbl.next; end; end;

Hmm... I came here looking for a solution, or confirmation that this was fixed in Delphi 11, but see that not only does it look like it continues, upgrading to Delphi 11 may actually create more instability issues. The new features they promote are nice, but what's more critical than new features for us is stability. I'm willing to miss out on features to stay on a more stable version. I miss the days of Delphi 7. What a fast and stable IDE that was! Add coderush to it, and it was my most enjoyable days of using Delphi. i still have an old project I maintain in Delphi 7 and have to go to it once a year or so, and everytime I go back to it I sigh and wish the more modern versions could be like it. These days it feels like I fight with Delphi more than enjoy it.