alank2

Thanks for the tip Remy; I'll give that approach a try as well.

Thanks Anders; my code snippet above was from within ServiceExecute. I appreciate the explanation, that makes sense!

I am using TSslHttpCli to access a webapi that requires NTLM. An odd thing is happening. With their production environment, it works, but with their development environment, it doesn't. I have tested both with curl using the --ntlm option and with curl, they both work, but with my code/ICS, only the production works. With the development I get a "401 - Unauthorized: Access is denied due to invalid credentials." returned. I thought it was their login in formation, but since it works with curl I have to assume there is something different in their webapi between the two environments. Are there any settings or things I can configure in ICS to try something different? I am setting: SslHttpCli1->ServerAuth=httpAuthNtlm; currently. I also upgraded from ICS 859 to 869 with no change in behavior. production api still works, development api does not.

I saw those notes, but I wondered if they meant that a system follows the compatibility level of the registry setting. I figured the compatibility level that the library/components were using was separate from that, or is LmCompatLevel picked up someone from the registry somewhere?

After looking through the source recommended above (OverbyteIcsHttpProt.pas and OverbyteIcsNtlmMsgs.pas), I found a LM compatibility level. It was set to 0 and I don't see it exposes in the properties of SSLHTTPCli, but I changed it using: SslHttpCli1->LmCompatLevel=1; And this fixed the issue!

Thanks FPiette and Angus for the help; I appreciate it!

Thanks for the tips - I'll take a look at the two pas files and see if anything jumps out. >You might also try tracing through the different messages passed during the handshaking to see where it dies. I'm not sure how to do this exactly. Could I attach the .pas to my project and then set some breakpoints? >Are your two environments running the Windows Server version?  They say they are the same, but I have to think there is something different. I appreciate the help!

I appreciate the reply Angus; I think this particular webapi is going to be changed next year anyway, so maybe I can live without the developer environment until that happens. Just trying to see if there was anything else I could try tweaking.

Thanks Angus - I was only trying to build for Win32. My attached zip file fixes it for VCL. One change was adding a pragma link for ncrypt and the other was changing 110 to 103. I have no idea about the Forms error for FMX though.

I installed icsv869.zip today with cppbuilder 10.3.3. I had to change two files based on a post on the first page of this thread (see attached zip for modified files). Common and VCL will compile and install with these changes. I tested it with my project and it also works. I tried to also compile fmx run, but it fails with: icsv869_changes_for_103.zip

I've got a web API I am trying to communicate with that uses ntlm. I have to use the --ntlm command line option with curl or it will fail. Does TNetHTTPClient support this type of web API?

Thanks for the links; I'll check them out. So does that mean that TNetHTTPClient does NOT support NTLM?

There are a whole list of functions here, but it seems some are depreciated and others not: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/UTF-8_Conversion_Routines Many VCL/FMX properties use UnicodeString, so when working with them, if you want to convert to UTF-8 and back, what do you use? One is UTF8ToUnicodeString, but I don't see its reverse which I would have expected to possibly be UnicodeStringToUTF8 ?

Thanks everyone; I'll take a look at UTF8String!

That really is the question isn't it. What I've *been doing* is using wchar_t in cppbuilder, but looking at that now, I'm wonder if that is the best approach or not. Most of the text I work with is going to fit in 7-bit ASCII, but if wchar_t has to use surrogates to support all of Unicodes 17 planes anyway, why not just use UTF-8 which is perhaps more efficient as well anyway? I found this site which is certainly pro UTF-8: http://utf8everywhere.org/ My question is, for modern cppbuilder development, is it better to use wchar_t or go back to char and assume it is UTF-8? Both have the issue of variable code points possibly being one character anyway. If so, then are the conversions to and from the UnicodeString's that VCL/FMX uses worth dealing with, or does it make more sense to just store them in a wchar_t. So many things have to be converted to char for the outside world anyway. I know there may not be a one thought fits all on this, so I just wanted to get everyone's opinion.

Thanks Remy; will check it out.

Thanks - after failing and returning from the succeeded function, EAX is 80040265 https://www.remosoftware.com/info/how-to-fix-80040265-error-in-windows-media-player I also found this page: https://docwiki.embarcadero.com/Libraries/Alexandria/en/FMX.Media.TMediaCodecManager It shows in windows that mp4 is a registered extension in the top table, but then below it only shows avi and wmv for windows video...

I created a Delphi project to try to dig into this. Debug dcu's are on. I trace it down to this function, but if I try to trace into it first must call the PChar and then with trace into it looks like it ends up in the windows message loop so I'm not sure how to find the RenderFile method to see what is going on there. Some more searching and I found Winapi.DirectShow9.pas which contains information about RenderFile I tried to set a breakpoint on it, but it doesn't stop. Is there a way I can find out the HRESULT it is returning? It looks like they are listed here: https://docs.microsoft.com/en-us/windows/win32/api/strmif/nf-strmif-igraphbuilder-renderfile Could AddSourceFilter have something to do with solving this?

Thanks Remy - I'll see if I can figure out how to go the debug DCU route and see what I can find out. I will also try a few other MP4's to make sure it isn't a certain one giving issues.

I tried CoInitialize(NULL) and also CoInitializeEx(NULL, COINIT_MULTITHREADED) in FMXmain - same error. Do I need to register the mp4 somehow? I saw a mention of this, but it was in Delphi.

Hi Remy, >did you initialize the COM library beforehand?) What do I need to do to do this?

Any other thoughts / things to try?

Hi Remy, 10.3, Windows 10 It plays fine when double clicked and I also tried the Ocean.mp4 from the Embarcadero VideoPlayback sample. I even tried compiling the sample. The artifacts were when playing the AVI (the only file that would play), they looked like a failing video signal with part of the image updated, etc. I could try another AVI to see if it plays properly, but I really want to get the MP4 playing if that is a possibility. I tried what I saw you suggest in that stackoverflow post (#include <FMX.Media.Win.hpp>), but it fails with a ton of errors and won't compile if this header is included. I appreciate the help!

I right clicked the speed button and chose Edit Custom Style. I replaced the background with a TRectange and set its fill to the color I want. It works on my development system (Win10), but when I take it to a Win7 box, it does not work and the background color is not there. In the style designed it says Platform Windows 10 Desktop, but the only other option is Default. When I select default it does not have a "SpeedButton1Style1". Any way I can set this to work on any system that runs it?

Thanks Serge; I will give this a try. My solution yesterday was to just put a TImage on top of the speedbutton and change hittest/align=client.