Jump to content

Dalija Prasnikar

Members
 View Profile  See their activity

  • Content Count

    1062

  • Joined

  • Last visited

  • Days Won

    91

Posts posted by Dalija Prasnikar

  1. Posted

    5 minutes ago, Clément said:

    Except, maybe I will give FMX another try. Hopefully FMX will improve faster without ARM. There's a lot to catch either to match VCL counter part or Android Studio! 

    I assume you meant "FMX will improve faster without ARC. "

     

    But, no, FMX improvements (as in framework improvements) are in no way related to memory management model. The only difference between FMX and VCL code related to memory management is that FMX calls DisposeOf to release FMX components and VCL calls Free. Bottom line, FMX will just run faster on mobile platforms without ARC, but that is it. 

     

    Other improvements will come (or not) unrelated to the memory management mode change.

    • Like 3

  2. Posted · Edited by Dalija Prasnikar

    43 minutes ago, David Heffernan said:

    Unification is good. Going to cause headaches for anybody with ARC only code. Don't think that's going to be an easy migration path.

    While anything is possible, I don't think there is too much ARC only code around. For anything TComponent based ARC was never working in the first place (you had to use DisposeOf) so most of UI code should work as-is.

     

    Since manual memory management is what people are used to, migration path should be relatively easy, although it may be harder to find exact places where object needs releasing. I would follow constructors .Create - usually destruction is somewhere nearby - either in Destroy, or in the same method. Also, on mobile small leaks are not that critical, usually applications are killed anyway before such leaks cause substantial problems, and larger leaks are easily found just by looking at code.  With Instruments and Android Studio you can easily spot problematic parts of  application with large leaks.

     

    Not ideal situation... but what is done is done.

    • Like 1

  4. Posted

    44 minutes ago, Fr0sT.Brutal said:

    You're absolutely right but careful handling of OOM errors will be far from trivial and probably will not ever happen (considering OS virtual memory mechanism). And there's little an app could do in such case. Nevertheless, I'd read any resources on this subject with pleasure. 

    var
  Strings: TStringList;
begin
  Strings := TStringList.Create;
  try
    Strings.LoadFromFile('C:\SomehugeFile.txt');
  finally
    Strings.Free;
  end;
end;

    Above is trivial example that can easily cause OOM error and it is also simple to handle and fully recoverable. You can easily wrap the whole thing with try...except block, show message to the user and application can merrily go on like nothing happened.

     

    46 minutes ago, Fr0sT.Brutal said:

    And I don't think this design is good 🙂

    We disagree then. 

     

    Maybe my imagination is at fault, but I have really hard time imagining how would solution with non-throwing constructors be simpler to handle and make code less complex and convoluted.

    • Like 1

  5. Posted

    25 minutes ago, Fr0sT.Brutal said:

    Indeed. Everything depends on those classes, whether their creation could fail or not. Anyway the ability of exception in constructor seems to me like a hidden trap (not talking about alloc errors on low mem available - I suspect only a few specially prepared programs could survive this case).

    Every instance construction can fail because of out of memory error.  But there is nothing special in surviving such exception. It only depends what you are doing at that time. Whether it will be recoverable error or not depends on the developer.

     

    Also throwing exceptions during construction is not a trap... Delphi has mechanisms in place that allow full cleanup and recovery. That is all that matters. If we didn't have exception throwing construction, we would still have to deal with all kind of "exceptional" situations where you would have to be prepared for handling them. And it would not be any simpler than what we have now.

     

    Basic problem in this particular case is non trivial ownership transfer, not the exception throwing constructors per-se. Solving ownership transfer solves the problem. Moving construction of dependent class to within owning class eliminates ownership transfer and solves core issue. (Another approach would be using reference counted classes and automatic memory management)

    • Like 2

  6. Posted

    19 minutes ago, Fr0sT.Brutal said:

    With current construction

    you have to create an instance in the outer scope thus enlarging the code.

     

    Construction the instance in outer scope is indeed the problem here, but your code still constructs the instance in outer scope. In order to prevent all leaks, instance must be constructed from within the constructor because exception could be raised before constructor chain is called. In such case you still leak TSomeOtherClass instance.

    • Like 1

  7. Posted

    6 minutes ago, dummzeuch said:

    How would DI (I guess you mean dependency injection) solve this problem? Can you please give an example?

    Same way like other approaches (besides interface) by moving construction of TSomeOtherClass instance to TMyClass constructor. Example would depend on DI framework used... I would look at Spring4D...

     

    If code is used in places where out of memory is not recoverable error, then ignoring this potential leak is also viable approach in combination with assigning instance at beginning of constructor like @Uwe Raabe suggested

    • Thanks 1

  8. Posted · Edited by Dalija Prasnikar

    21 minutes ago, Uwe Raabe said:

    Or are there situations where TMyClass.Destroy is not called?

    If allocating memory for the object instance fails then destructor is not called. 

     

    I would probably use try..except block for releasing the object in case of out of memory error. Of course, that works only if constructing TMyClass instance itself is the only thing that can cause out of memory in that process.

     

    But I don't really like that whole try...finally block with nil assignment. 

     

    Cleaner approaches would include DI, interfaces, passing meta class to  TMyClass constructor and constructing TSomeOtherClass instance within the constructor, if the construction is too complex then I would use anonymous method instead and use it as factory. 

    • Like 1

  11. Posted

    This certainly seems like device with dark mode turned on, since TEdit uses native device rendering.

     

    There was announcement for 10.3.3 that said plan was to support iOS 13 dark mode https://community.idera.com/developer-tools/b/blog/posts/addressing-ios-13-and-android-64-bit-with-rad-studio and the release notes http://docwiki.embarcadero.com/RADStudio/Rio/en/10.3_Rio_-_Release_3 also mentions dark mode support. But, I cannot find those settings (under Project Options - Version) available in IDE. 

     

    Maybe it is a bug or it is just too late here...

  12. Posted

    If you can switch to 64bit, this is the fastest way to solve intermediate memory issues that are not caused by memory leaks.

     

    However, additional information about what exactly you are doing would be helpful. Memory issues can have number of causes and solutions depend on root cause.

     

    For instance, what kind of file(s) you are importing? How are you processing them?

     

    Importing 300 MB XML can easily kill 32-bit application. Even smaller than that can be problematic depending on particular code. Also, if you are parsing textual data, using UTF8String for processing generally reduces memory consumption by half (for Western character sets). Creating DOM is also wasteful, using SAX parsers for XML is faster and consumes less memory.... base64 encoding, decoding can also be a memory killer if you are doing it in memory, with strings... 

     

    Like, I said... more information is needed for better diagnostic...

  17. Posted

    2 hours ago, Yaron said:

    I was able to modify the style to me desire, called it "mytheme.vsf",

     

    When trying to apply it in the registry by setting "Theme" to "Custom" and "VCLStyle" to "mytheme.vsf" (after placing the file in "c:\Program Files (x86)\Embarcadero\Studio\20.0\Redist\styles\vcl\").

     

    However, Delphi doesn't seem to be using the style, what's more, after restoring the registry setting, if i look under the themes pop-up-menu (clicking the little window-moon icon), the "custom" entry is grayed out.

    VCLStyle entry in registry is not the name of the file, but name of the style in Editor - without .vsf.  

     

    stylename.png

  18. Posted

    10 minutes ago, Yaron said:

    What do I use to extract the resources and what do I use to them rebuilt the file and make it accessible in the IDE?

    Remember, I only need to change a few RGB values, not really anything too complex.

     

    I guess if I can't share my work, I'll just document which values I changed.

    For extracting resources Google for PE resource editor. You don't have to rebuild bpl again, just put your VCL Style in common path where IDE can find it (where other VCL Styles are located) and then change following keys in registry:

     

    Computer\HKEY_CURRENT_USER\Software\Embarcadero\BDS\20.0\Theme

     

    Key: Theme

    Value: Custom

     

    Key: VCLStyle

    Value: YourStyleName (That would be the name you give in VCL Style Editor under Name

     

    Unfortunately, VCL Styles are bitmap based and you cannot just change few RGB color values, you have to edit bitmaps. You can export complete style as one PNG and then you can edit colors in some image editing tool. After you are done, import new image back in.

    You will also need to go to Style -> Assign Colors to apply colors from bitmap back to Colors and SysColors. After that check if all those colors are correct (I think few were not assigned correctly)

     

    Depending on how much customizing you need and want, it can be a lot of work. 

     

    I modified Light theme to grayscale, but that was rather easy as I just converted whole png to grayscale (except for the close button)

    • Like 1

  19. Posted

    There are few problems here.

     

    First, IDE themes are slightly different from general VCL Styles so you cannot use them because some parts of IDE will not be painted properly. Next VCL Style editor is rather hard to use for creating any theme from scratch. 

     

    Your best option would be to extract theme resource from darktheme260.bpl (haven't checked if this is the right bpl, as I have customized light theme), and then use that resource as starting point for your customization. 

     

    IDE themes are copyrighted, so you should not distribute such hacked theme.

  23. Posted

    1 minute ago, Yaron said:

    Without any rationale?

    Don't remember exactly... but something along the lines implementing support for <LF> would be too much work, so make sure you have correct line endings in your code.

     

    There is also option to autocorrect while saving so that helps with pasting code... where it does not help is if your VCS messes your endings.

×