![Delphi-PRAXiS [en]](https://en.delphipraxis.net/uploads/monthly_2018_12/logo.png.be76d93fcd709295cb24de51900e5888.png){kind=logo}
All Activity
This stream auto-updates
- Past hour
-
What is the reason for this code in TTestDataProvider.GetProvider?
Uwe Raabe posted a topic in DUnitX
The current implementation of one overload of TTestDataProvider.GetProvider looks like this: class function TestDataProviderManager.GetProvider(const AClass: TTestDataProviderClass) : ITestDataProvider; var key : string; begin result := nil; if (FList.ContainsValue(AClass)) then begin for key in flist.keys do begin if (flist[key] = AClass) then begin result := TTestDataProviderClass(flist[key]).Create; break; end; end; end; end; Is there any reason why that cannot be written as: class function TestDataProviderManager.GetProvider(const AClass: TTestDataProviderClass) : ITestDataProvider; begin result := AClass.Create; end; With that one could avoid registering the provider. The reasoning for my question is, that I have a base provider class and several derived classes to overcome the lack of ability to parametrize a data provider instance. All these derived classes are local to one test unit and I would like all of them to have the same class name. Unfortunately the registration requires me to give distinct names for them and you know - naming is hard. Just declaring the derived class and use that in a TestCaseProvider attribute would simplify this a lot. Concrete: TTestDataFilesProvider provides a list of files, but requires the path and search pattern as parameters. Now I derive individual classes (with fixed values) immediately before they are used. -
This is a complete routine that should work: procedure OpenApplication(const AFileName: string); var LMimeType: JString; LIntent: JIntent; begin LMimeType := TJMimeTypeMap.JavaClass.getSingleton.getMimeTypeFromExtension(StringToJString('apk')); LIntent := TJIntent.JavaClass.init(TJIntent.JavaClass.ACTION_VIEW); LIntent.setDataAndType(JFileToJURI(TJFile.JavaClass.init(StringToJString(AFileName))), LMimeType); LIntent.setFlags(TJIntent.JavaClass.FLAG_GRANT_READ_URI_PERMISSION); TAndroidHelper.Activity.startActivityForResult(LIntent, 999); // 999 is just a random value - it won't matter what it is end; Note the extra line regarding FLAG_GRANT_READ_URI_PERMISSION.
- Today
-
Ok. I did that and saw how the new provider_paths.xml was placed in the Android64\Debug folder, and also added to deployment page. Now when I run the app, the call to TAndroidHelper.Context.startActivity(Intent); seems to go to la-la land... No window pops up asking if I want to update, like it would if I ran the apk from the downloads folder manually. I do see my app state go through WillBecomeInactive, then BecameActive, but no prompt to install/update and no error message. Here is an important detail maybe... the apk I'm launching is the same version I'm running... it is not actually an update. Could that be why it doesn't show the install window? Or could it be a permission problem still with launching an apk from my app? Your help is really appreciated.
-
I've tried that. It doesn't work.
-
Sorry.. missed a step. Delete AndroidManifest.template.xml in the project folder. The IDE will recreate this. If you have made any customisations to it, you will need to ensure you reinstate those after it is recreated.
-
How to make bug report on sf?
-
Looks to be an issue with https - over http it works
-
Thanks! I have removed the provider section from manifest. I do have secure file sharing checked in entitlements list. With the change you suggested my error has changed: Project JCMTime.apk raised exception class EJNIException with message 'java.lang.IllegalArgumentException: Couldn't find meta-data for provider with authority com.zunna.JCMTime.fileprovider'. Unless you have a quicker solution I will try the steps laid out here: android - Couldn't find meta-data for provider with authority - Stack Overflow Although... that seems almost like the same xml I had before?
-
This should be: Intent.setDataAndType(JFileToJURI(F)), StringToJString('application/vnd.android.package-archive')); JFileToJURI uses the FileProvider class to create the correct URI You won't need to do that if you check the Secure File Sharing option in the Entitlements List in the Project Options. This also creates and deploys the required xml file.
-
In 2015 or so I used Berlin to create some android apps. I'm primarily a Windows developer, so that was a painful process. I need to update those apps so they run on new android versions, but I'm running into several issues. I am happy I found this group, I have found a lot of good advice, but I have a feeling like answers change every couple of years, and so far I have not figured out a few things. I know very little about android development, which is why I struggle, so any direction where I can learn more is much appreciated. First thing is, I want my app to self-update by downloading an apk and running so user can install if wanted. I have async download working, so that is good (threads are also new to me). My code that runs the update is below. I get the following error: Project JCMTime.apk raised exception class EJNIException with message 'android.os.FileUriExposedException: file:///data/user/0/com.hello.world/files/BigTime64-4.1.apk exposed beyond app through Intent.getData()'. Here is one version of the code I've tried: procedure TDMCommon.initiateUpdate; var F: Jfile; Intent: JIntent; begin F := TJfile.JavaClass.init(stringtojstring(UpdateFolder),stringtojstring(UpdateFN)); Intent := TJIntent.Create(); Intent.setAction(TJIntent.JavaClass.ACTION_VIEW); Intent.addFlags(TJIntent.JavaClass.FLAG_ACTIVITY_NEW_TASK); Intent.setDataAndType(TJnet_Uri.JavaClass.fromFile(F), StringToJString('application/vnd.android.package-archive')); TAndroidHelper.Context.startActivity(Intent); end; I've tried adding the below to manifest file: <provider android:name="androidx.core.content.FileProvider" android:authorities="com.hello.world.fileprovider" android:exported="false" android:grantUriPermissions="true" android:exported="false"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/filepaths" /> </provider> with following filepaths.xml file deploying to res\xml\: <paths xmlns:android="http://schemas.android.com/apk/res/android"> <root-path name="root" path="." /> </paths> but I'm not even sure I need those things. Any feedback is appreciated... I think the biggest problems I have are 1) lack of active delphi discussion groups, 2) programming that worked 2-3 years ago no longer works, so even when I find a relevant article/post it doesn't mean hooray, and 3) I am really uneducated about android development. Thanks for any feedback.
- Yesterday
-
Bug report on SourceForge please.
-
This has already been fixed according to QP. In the comments, there is a provided temporary fix until an update comes out. https://quality.embarcadero.com/browse/RSP-37702
-
Access Violation while using GExperts with Delphi 11.1.5, you can try it.
-
I don't understand what this log is supposed to be showing me. Looks like every request received is responded to, and each connection is closed. What am I missing? What is the actual problem, exactly? Using HTTPS through an HTTP proxy requires use of the CONNECT verb, which is just a straight passthough tunnel of raw data from the client to the target server and back. TIdHTTPProxyServer does not attempt to interpret the raw data in any way, all it is doing is managing the 2 TCP connections involved. Whereas, using HTTP through an HTTP proxy requires sending HTTP requests to the proxy itself, and then the proxy makes its own HTTP requests to the target server. So TIdHTTPProxyServer by default is fully reading and interpreting your client's requests and then replicating them to the target server. So sure, there could certainly be some glitches in that process. TIdHTTPProxyServer is not a full HTTP server or HTTP client, it is quite bare-bones, so it is not outside the realm of possibility that RemObjects is sending its HTTP requests in a way that TIdHTTPProxyServer can't handle correctly. Or, because TIdHTTPProxyServer uses HTTP 1.0 when communicating with the target server, there could be differences between its use of HTTP 1.0 and the client's use of HTTP 1.1 that is causing interference. Hard to say for sure. I'm speculating, because I have no way to actually test/debug this at the moment. Something else to consider - by default, TIdHTTPProxyServer.DefaultTransferMode is set to tmFullDocument, which means for GET/POST/HEAD requests, TIdHTTPProxyServer will read the client's entire request into memory before then passing it along to the target server, and then read the server's entire response into memory before then passing it along to the client. This allows the user's application code to modify the request/response data if desired before passing it along. Do you have the same problem if you set TIdHTTPProxyServer.DefaultTransferMode to tmStreaming instead? That will cause TIdHTTPProxyServer to not buffer the request/response data in memory, it will be passed along as it is being received (at the cost that application code can't modify it anymore).
-
Delphi CE 10.4.2 - Command Line Compilation
Remy Lebeau replied to PawelPepe's topic in Delphi IDE and APIs
Well, that sucks -
Probably because the default "if" template is under C:\Program Files (x86)\... which is read-only. I'm guessing Delphi removes it from it's run-time list while it is open but re-populates the list from the files when it starts back up--and since the file itself was not deleted, re-reads it. If you really, REALLY want that "if" template to go away, close Delphi, manually delete C:\Program Files (x86)\Embarcadero\Studio\21.0\ObjRepos\en\Code_Templates\Delphi\if.xml, then re-start Delphi.
-
exceptions and static storage duration objects
Remy Lebeau replied to Fraser's topic in General Help
I'm just going off of the actual code you posted earlier. That tends to happen when the runtime/debugger can't interpret the actual exception object at the level it was detected at, basically treating it as an "unknown" exception type. Did you not see the quote I posted earlier? https://en.cppreference.com/w/cpp/language/function-try-block Minor nitpicks: the A() constructor is not public, and std::exit() takes an exit code integer instead of a string as input. In any case, when I test the code outside of C++Builder (which I don't have installed at the moment), the code works fine when using std::exit() in the function-try's catch handler: https://onlinegdb.com/WqiBtg8dD https://onlinegdb.com/v7B8acNo4 And terminates the process with a re-thrown exception when not using std::exit() in the handler: https://onlinegdb.com/q0KLc6Cne https://onlinegdb.com/rHqvw5kmo -
Thank you for your advice. Despite using the same working directory, TensorFlow is indeed loading CUDA DLLs from a different location with Python4Delphi.
-
Hello, I'm using a TIdHTTPProxyServer component to create a proxy server for our application. Unfortunately the proxy server frequently blocks communication. As a test, I put a TIdHTTPProxyServer on a form and use this proxy i.c.m. with a call to a RemObjects server. I added an interceptor to log the output of the proxy component (see attachment). From this file I can see that the proxy server hangs on this call (see also attachment): 127.0.0.1:12719 Stat Connected. 127.0.0.1:12719 Recv 12/08/2022 15:59:26: POST http://service.a-dato.net:80/handler.ashx/binmessage HTTP/1.1 Host: service.a-dato.net Keep-Alive: 300 Proxy-Connection: keep-alive User-Agent: Remoting SDK Content-Type: text/html Content-Length: 17 Accept-Encoding: identity Connection: keep-alive }Ðm�BÐ�@�Fx8‘¯®V� (data is binary) Comments: The first call to the server succeeds The problem comes on subsequent calls to the server (pressing 'Call service (8081)' multiple times) This problem only occurs when I use 'http' (using 'https' it works) It works when I use no proxy It works when I use another proxy (the second button will use Fiddler as a proxy server) When you run the test application, a logfile is written to 'c:\Temp\Log' I have attached a test application to replicate the problem. Thanks for your support and comments. Kees SimpleProxy.log ProxyTestMain.zip
-
I prefer to read rather than watching YT too. However, these days I find many solutions are on YT rather than in prose. I often play YT videos at 1.5 or 1.75 speedup so I don't waste as much time.
-
Ask for comments to improve this code
David Champion replied to Berocoder's topic in Algorithms, Data Structures and Class Design
Dont give up on better code :-). Migrate the name and method signature slowly to something better. Use the Deprecated key word and introduce the replacement. -
Not personal, but there is a reason why we use a webbrowser instead of a TV set. I like to read this kind of things instead of watching YT 😉 (just a comment)
-
More than once I have said the AccessA() type of implementation works as expected and you say otherwise. Thats ridiculous. You are the only person that has said anything about rethowing. I have seen nothing. For a start an object of one type, in my case std::logic_error, would be rethrown as the same object. But the next exception I witness, for object a, has type EExternalException. I'm not aware of any difference between function-try-block and try-block other than a function-try-block is a like a try-block around a functions entire body, a shorter notation for that. Even the standard states that where it says "try block" it can apply to either. Here is the rough mock-up of my program with some corrections; #include <vcl.h> #pragma hdrstop #include "Unit1.h" #pragma package(smart_init) #pragma resource "*.dfm" TForm1 *Form1; class A { A() noexcept try { throw std::logic_error("test"); } catch (std::exception const &ex) { std::cout << "Caught an STL exception" << std::endl; std::exit("Done"); } }; A a; // Alternative implementation that works as expected; /*A & AccessA() { static A obj; return obj; }*/ __fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { }
-
Scrap TVirtualStringTree using Win 32 api (SendMessage)
Fr0sT.Brutal replied to MaxBayne's topic in Windows API
Try it 🙂 accessibility was implemented relatively recently but I believe TVM_GETITEM had been there much longer -
Delphi CE 10.4.2 - Command Line Compilation
Fr0sT.Brutal replied to PawelPepe's topic in Delphi IDE and APIs
So I was right finally. Emba needs to change their feature matrix table
