mvanrijnen

Which Delphi version? In 11.3 there are a couple of overloads, but not that "overload version"? found it 🙂 overread the parameterless in your post that in combination with the .AddValue would be the solution

It searches for the param with the name, and changes the value (and other properties of the parameter) I don't think this is possible with the default parameters in the TRestRequest. You have to fetch the TRestRequest parameter and use the .AddValue method i think.

Thats very strange, You have assigned the correct TRestclient to the Request? I use 2 seperate (3 actually), TRestclients: * 1 for the requests * 1 for the Authorization * 1 for uploads (large files) So i can keep them seperate because they differ a little bit somesitimes (BaseURL especially) Preperation: function THSMSGraphAPI.NewRestClient(const ABaseURI: string): TRESTClient; begin Result := TRESTClient.Create(ABaseURI); Result.SecureProtocols := [THTTPSecureProtocol.TLS12, THTTPSecureProtocol.TLS13]; if not UserAgent.IsEmpty then Result.UserAgent := UserAgent; Result.ProxyServer := ProxyServer; Result.ProxyPort := ProxyPort; end; procedure THSMSGraphAPI.CheckClients; begin if not Assigned(FRestClient) then FRestClient := NewRestClient(CNST_MSGRAPH_BASEURL); if not Assigned(FAuthClient) then FAuthClient := NewRestClient(CNST_MICROSOFT_AccessTokenEndpoint.Replace(CNST_TENANTNAME, TenantName, [rfReplaceAll, rfIgnoreCase])); if not Assigned(FUplClient) then FUplClient := NewRestClient(''); end; procedure THSMSGraphAPI.CheckCreds; begin CheckClients(); if not DoCheckAuthorisation() then raise Exception.Create('Authorization fail.'); FRestClient.AddAuthParameter('Authorization','Bearer ' + AccessToken, pkHTTPHEADER, [TRESTRequestParameterOption.poDoNotEncode]); end; [code] warning, i only use client_credentials as grant_type a simple routine [code] function THSMSGraphAPI.FindCalendar(const ACalendarName: string; var ACalendarID: string; const ASkipCreds :Boolean): Boolean; var cal : TMSGraphCalendarListItem; cals : TMSGraphCalendarListItems; req : TRESTRequest; begin Result := False; ACalendarID := ''; if not ASkipCreds then CheckCreds(); req := TRESTRequest.Create(nil); try req.Client := FRestClient; req.Method := TRESTRequestMethod.rmGET; req.Resource := CNST_RESOURCE_LISTCALENDARS.Replace(CNST_SENDASEMAILADDRESS, AccountEmailAddress, [rfReplaceAll, rfIgnoreCase]); req.Execute(); if not LogInvalidResponse(req.Response, True, 'THSMSGraphAPI.FindCalendar') then begin TgoBsonSerializer.Deserialize(req.Response.Content, cals); for cal in cals.Value do if (cal.name=ACalendarName) then begin ACalendarID := cal.id; break; end; end; finally Result := not ACalendarID.IsEmpty; req.Free; end; end; (ps this code was just a quick way to get the calendar i needed, have to expand to the search/filter possibilities from MSGRaph API) i always create the clients&requests by hand in my final code.

very strange, try this 🙂 FRestClient.AddAuthParameter('Authorization','Bearer ' + AccessToken, pkHTTPHEADER, [TRESTRequestParameterOption.poDoNotEncode]); so, add the param to the client instead of the request, and use AddAuthParameter for this. (maybe try with settings this in the request also). tried all kind of variants, even pasted your code line, here it always works., you tried it with Execute instead of ExecuteAsync i think you should try a bit harder to get a proxy running for debugging this kind of stuf, works the best to find out differences. the different variants i tried, the last one is copied from your code posted here: // req.Resource := cExtensionResource; // FRestClient.AddAuthParameter('Authorization','Bearer ' + AccessToken, pkHTTPHEADER, [TRESTRequestParameterOption.poDoNotEncode]); // req.AddParameter('Authorization','Bearer ' + AccessToken, pkHTTPHEADER, [TRESTRequestParameterOption.poDoNotEncode]); // req.Params.AddItem('Authorization','Bearer ' + AccessToken, pkHTTPHEADER, [TRESTRequestParameterOption.poDoNotEncode]); req.Params.AddItem('Authorization', 'Bearer ' + AccessToken, TRESTRequestParameterKind.pkHTTPHEADER, [poDoNotEncode]); req.Resource := cExtensionResource; req.Execute();

type change this: RESTProfileRequest.Method := TRESTRequestMethod.rmGet; RESTProfileRequest.Resource := 'v1.0/me'; RESTProfileRequest.Params.Clear; to RESTProfileRequest.Method := TRESTRequestMethod.rmGet; RESTProfileRequest.Params.Clear; RESTProfileRequest.Resource := 'v1.0/me'; i think somethings get cleared with the params clear. second also instead of .Params. use .AddParameter with the Access token you mean the value in: FConnection.AuthToken ?

And make sure to use F9 (not ctrl-shift-F9), or hit the run icon with the bug.

They are all using the same TRestClient ? ( i always set these things manually) restClient.ProxyServer := Self.ProxyHost; restClient.ProxyPort := Self.ProxyPort; Could also be the case that you do not use the 127.0.0.1 address, but your non-localhost address (eg 192.168.1.44).

Yes, but the question is where the data changes? As i demonstrated that Delphi & .Net creates the same b64 data.

THe ThisWhatDelphiRestGet.txt file, is that the immediate output of your Delphi method? Because i thought (ot ouf my headnot checked) that the TNetEncoding.Base64.EncodeBytesToString method returns CR/LF's in its result? see here: program TestBase64Encoding; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.IOUtils, System.NetEncoding; const cSourceURL = 'https://file-examples.com/storage/fe1134defc6538ed39b8efa/2017/10/file-sample_150kB.pdf'; cInputFilename = 'C:\SWDev\_TestData\file-sample_150kB.pdf'; cOutputFilename = 'C:\SWDev\_TestData\file-sample_150kB.b64.delphi.txt'; cOutputFilename2 = 'C:\SWDev\_TestData\file-sample_150kB.b64.delphi-CRLF.txt'; begin try TFile.WriteAllText(cOutputFilename, TNetEncoding.Base64.EncodeBytesToString(TFile.ReadAllBytes(cInputFilename))); TFile.WriteAllText(cOutputFilename2, TNetEncoding.Base64.EncodeBytesToString(TFile.ReadAllBytes(cInputFilename)).Replace(#13#10, '', [rfReplaceAll])); except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end. .Net using System.IO; using System.Text; using System.Runtime.CompilerServices; namespace ConsoleApp { internal class Program { private const string cSourceURL = @"https://file-examples.com/storage/fe1134defc6538ed39b8efa/2017/10/file-sample_150kB.pdf"; private const string cInputFilename = @"C:\SWDev\_TestData\file-sample_150kB.pdf"; private const string cOutputFilename = @"C:\SWDev\_TestData\file-sample_150kB.b64.dotnet.txt"; static void Main(string[] args) { File.WriteAllText(cOutputFilename, Convert.ToBase64String(File.ReadAllBytes(cInputFilename))); } } } You can see that the CRLF stripped version is the same as the .Net version of the outputfile. Somethings mixes up the data for TS, Result: file-sample_150kB.b64.delphi.txt ile-sample_150kB.b64.delphi-CRLF.txt file-sample_150kB.b64.dotnet.txt

Are the totally different, or: - Is it just the padding that differs - Is the .Net B64 a long string, and the Delphi B64 is multilne (a string with CR/LF's in it?) Can you dump here the 2 different strings?, use a testfile!

ah, thats new for me 🙂 , in that case, dump the manual downloaded sqlite DLL 🙂 and just use FireDac

also for community edition?

It's one of the (many) main reasons, at the moment, (aside Costs/Investments & Time) not to move to other Development environment, yes. There's a lot of code in triggers etc, which is a factor not to move to other database, at this moment. Of course is moving to an whole other platform bringing a lot of costs and time, 20years of development in the main application here, it's not that we have that written to .Net (for example) in 6 months, probably will take years. okay Only thing was a bit overdone 😉

Probably some needed DLL which is not on your system (or incorrect version), can you see something in the windows event viewer (Windows -> Application logs) ? or try to run it from a seperate cmdline instance, maybe you then see some error message? or try to trace what files are tried to be loaded using procmon (from sysinternals).

In C#/,Net i (years ago) intercepted the DLL loads (long time ago), i could log them, and maybe (can't remember divert them). Within that method i could test versions (for win32 dll as for ".net assembly dll") and decline them. (Was nice back then to find out .Net searched DLL's in another place on devices with VisualStudio installed on them)

Move to a production Environment which is: - More affordable (read for more less expensive) - More supported - Far more developers worldwide - More 3th party components/development - Developed with a longterm vision, not a "grab as much money as you can" vision Only thing whats holding us back is the transition to a whole new environment, we probably should move from DB also (because we're "locked" to Interbase at the moment). But we'r getting there, more and more Management thinks with us, so gonna see wich new projects can be (partly) be done in a new development ecosystem. It's a pitty with me (with me Colllegue) think that Delphi (or better Pascal) is one of the most practical/readable dev languages whilest compiling one of the most fastes executables (win32). (I started with TurboPascal 5.5, good old times 🙂 ). The sneaky way how EMB moved the subscription from backwards support (whats was the promise when we started with it) to the only fixes in new releases (with new bugs) was/is really a stab in the back to developers. It's really a product of this century, "how to get as much out of our customers with the least effort", lock and squeeze. The example of not getting the LSP (codecompletion, error in sigth and others) in order in many years is the perfect example for this. Maybe it finally fixed in version 15.xxxx and we are tenthousands of dollars investment in the product (as customer) further down the road. Now i go back to work 🙂 , pretend to be happy with 11.3, which i have to start half of the times of his predecessor. [edit] It's a feeling like, paying for a new Mercedes E series but driving a 20year old Ford Ka.

maybe another tip, try somethings like https://mitmproxy.org/ to spy on the request you send. if the request works with Postman but not with your code, something has to be different. [edit] Can something go wrong because you use the ExecuteAsync, can't see that with the code you proviced ? (try it with Execute and see if if works then?)

i have this, maybe you can the with the scope i use, i only use Application type, not Delegated: LRequest.AddAuthParameter('scope', 'https://graph.microsoft.com/.default', TRESTRequestParameterKind.pkREQUESTBODY); i read that it works with postman, so it would not be the scope then. i'm trying to remember because i've had problems in the beginning also with authorization with the msgraphapi (i needed the poDoNotEncode) The RestRequest method = rmGet i assume?

How do you get your accesstoken ? You use the right scope when you do this?

Never used TZip after i discovered a few years ago that it accepted large files without error/exception, but they wouldn't be in the zip 😞

i think @Fr0sT.Brutal meant, to run it without real comping, so you can see if delay is in starting the Exe itself of the compiling process.

Try to: Add sourcecode folders as exclusion for AV. Add your programs own work/temp folder as exclusion for AV. If the compiler creates executables (or object files), make sure these are linked/copied into a folder checked with the AV.

Already taken 😎

Make an aftershow method, See here: SwissDelphiCenter.ch : ...implement AfterShow, AfterCreate events? I use this in baseforms, added a "FirstShow" boolean in the form, so you know if you have to do all calcs all the time or nly one time. So in my base form i have protected methods like procedure DoBeforeShow(const AFirstshow : Boolean); virtual; procedure DoAfterShow(const AFirstshow : Boolean); virtual;

i'v had this problem while back when using the MARS library for example (BitDefender), while others didn't. It's sometimes a weird thing. But there are always have been things about this with Delphi compiled software somehow.