Jump to content

Koru

Members
  • Content Count

    20
  • Joined

  • Last visited

Community Reputation

2 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Koru

    Missing Buttons

    It always happens with the same elements of the same form or is it something random along the whole application? Faced with strange problems of the visual part, I would also check that there is no thread that touches visual things without the correct synchronization
  2. Koru

    Missing Buttons

    I would look for all the pieces of code that can cause that behavior or touch those components in some way, and leave a log when they are executed making it clear in the log what part of the code has been executed. In the log I would place also information about the new state of the components: position, visible, enabled,...
  3. Koru

    Firedac Sqlite bug?

    In 10.4.1 and 10.2 update 3, it executes ok
  4. Koru

    Delphi 10.4.1

    yes
  5. Koru

    Delphi 10.4.1 LIBSUFFIX AUTO

    Did the same test and same problem, but on Win32. On Win64 it works properly for me
  6. Unfortunately we are nothing new with Delphi, although we may seem so, but with a halo of hope. Ok, the opinions are clear, we continue with the fight on our own. Thank you very much to all
  7. Yes, we are asking for a wish list, without knowing the technical details. The context is 'Embarcadero says they can do it', and we look for ideas that come from people who have stuck with current interfaces, know the limitations they have and would like to solve. All this knowing that then Embarcadero will probably do it his way. But who knows ... maybe they'll hear us on something. And that was the idea. I am sorry that we do not know how to help you more in the technical section, because we only wanted to move in the ideas leaving aside how it is done. In another post Javier says 'there is already an embarcadero answer on Quality portal, acknowledging this is feasable, and would work as expected'...reason why we believe that the technical aspect is solved already by Embarcadero, but any doubt that there is in this regard can also be presented to Embarcadero for clarification if possible, with specific questions. So I understand what you ask Stefan, and maybe there is some detail in the comments of the link at the end that clarifies you something, or even you can ask any doubt there directly (they are answering all our questions so far): https://quality.embarcadero.com/browse/RSP-27911
  8. copy/paste problem, sorry 😅
  9. Methods (including interface methods) and method pointers are different language elements and they are not compatible. Technically, a method pointer is a TMethod element (Code+Data). We are talking again about the particular way it has been implementedJust for a moment, forget the implementation, and look at the question from the programmer perspectiveWhy should not be able to use an interface method as an event method? Behind every and each interface there is an object
  10. The usage of the native interfaces must be more or less the same as the com based, I mean the declaration should be more or less equal maybe with some new reserved word, and the implementation in a class should be similar also. A silly example could be: IMyTest= nativeinterface ['{16E3EB88-4654-495A-9699-AC9FA2612352}'] procedure DoProc; function DoFunc: Boolean; end; TMyTest = class(TNativeInterfacedObject, IMyTest) public procedure DoProc; function DoFunc: Boolean; end; With actual interfaces you can't do next (Button2Click will fail at compile time): type TProcTest = procedure of object; TFuncTest = function : Boolean of object; IMyTest= interface ['{16E3EB88-4654-495A-9699-AC9FA2612352}'] procedure DoProc; function DoFunc: Boolean; end; TMyTest = class(TInterfacedObject, IMyTest) public procedure DoProc; function DoFunc: Boolean; end; TExecutor = class public procedure ExecuteIfCheckIsTrue(const AExec: TProcTest; const ACheck: TFuncTest); end; TForm67 = class(TForm) Button1: TButton; Button2: TButton; procedure Button1Click(Sender: TObject); procedure Button2Click(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form67: TForm67; implementation {$R *.dfm} { TMyTest } function TMyTest.DoFunc: Boolean; begin Result := True; end; procedure TMyTest.DoProc; begin ShowMessage('Hi!'); end; { TExecutor } procedure TExecutor.ExecuteIfCheckIsTrue(const AExec: TProcTest; const ACheck: TFuncTest); begin if ACheck() then AExec(); end; procedure TForm67.Button1Click(Sender: TObject); var L1: TMyTest; L2: TExecutor; begin L1 := TMyTest.Create; L2 := TExecutor.Create; L2.ExecuteIfCheckIsTrue(L1.DoProc, L1.DoFunc); end; procedure TForm67.Button2Click(Sender: TObject); var L1: IMyTest; L2: TExecutor; begin L1 := TMyTest.Create; L2 := TExecutor.Create; L2.ExecuteIfCheckIsTrue(L1.DoProc, L1.DoFunc); //this statement doesn't compile end; But this should be possible with the native interface. Things like this, from the developer point of view looks like it should work (at least from my point of view ), we should not know that the interface comes from COM and all that history...so you can't do this and this an this...but...you can do all that things with the class that implements that interface. If you don't know the internals of the issue it's weird, and a little bit inconsistent... There are probably considerations that those of us who are not experts miss along the way, but the usefulness seems clear
  11. Putting proper names always leads to headaches And it is relevant, but it is not the goal of the post. The goal is to know what deficiencies or limitations we see to the current interfaces in Delphi, partly (or mostly) because they were born from COM. By native interface we have been calling in the post to that interface that we know that behind it has a Delphi class, and under that assumption I would like things like the ones I list in the first post, that probably would be enough advance for me: 'As an example, you can't use an interface method as an event handler. You can't use anything that expects a "procedure of object" or "function of object", nor use generics or other modern features' But I know that there are people like you who that have struggled a lot with the interfaces and I'm sure you have clearer limitations that perhaps I can't see.
  12. I have the feeling that we are talking about how it works now (you correct me if I'm wrong), not how we would like it to work, and I talk about how I would like it to work. In this specific case if the native interfaces have inheritance capacity, these possibilities would be viable, if they are clearly useful for the developers of course
  13. Hi, not having an extensive knowledge of the subject can lead me to erroneous statements, if so, do not hesitate to correct me. If we talk about a new implementation of the interfaces as native interfaces, no longer tied to COM, I understand that Embarcadero can make those limitations cease to exist, is what I say correct or is there something I am leaving out?
  14. Hi again, why do you see it logical? I think it seems quite illogical to ask that to this function and to answer that it's false when we know it's true
  15. Hi, yes I was referring to something like this case you point. Well, it may be that the approach was not very correct. My idea focused on a context where we can ask native interfaces for information similar to what we can ask to classes, such as for example: if it inherits from a certain base interface. And in that context I was handling the idea (perhaps wrong, we are talking about ideas and giving possibilities) that the Supports function was capable of giving that functionality
×