alank2

I don't think these directives work in a DEF file.

I have a project that builds a DLL and I have two different .DEF files (one for WIN32, and for WIN64).  I want to avoid making two projects and so I've been removing/adding the correct .DEF file before I build that platform, is there a better way?

Is there a way to do this?  What I have done successfully is create functions that access the class, put them in a DLL, and then call that DLL from Delphi which does work, but if there is another way it is probably an easier way.

How would you wait for the thread to stop?  The current method does wait for any process running to finish.  I get how to trigger the thread to stop using the onstop/onshutdown events, but where do you actually make it wait on the thread?

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 have a C++ Builder service application that uses a timer TProcess to do something every 60 seconds.  The "something" was processing some data and making a SQL call.  I was accessing one of the query columns outside of a try catch block and it was throwing an exception because I was accessing it as an integer and it was a bit type and needed to be accessed as a boolean.  I get the error and how to fix it, but I am trying to troubleshoot how to stop the exception from being unhandled at a higher lever then leaving the service in a stuck state.

  try
    {
      while (!Terminated || !TProcess->Enabled) //do not quit if process is running until it is finished
        {
          ServiceThread->ProcessRequests(true);
          Sleep(250);
        }
    }
  catch(Exception &exception)
    {
      log1.Logf(L"ERROR: %s (main loop)", exception.Message.w_str());
    }

At first I just had what was in the try block above on its own.  Then I wrapped it in the try block and expected that this would catch the exception and at least log it.  What I don't understand is why the above did not catch the exception.  I repeated the test and it still hung with no log message.  When I moved the code that accesses the SQL field into its own try catch block with logging, it did log the error related to the issue.

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.

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.

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

Thanks for the links; I'll check them out.

So does that mean that TNetHTTPClient does NOT support NTLM?

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

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