Jump to content

Brian Evans

Members
  • Content Count

    295
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by Brian Evans


  1. Short answer: No test case no fix.

     

    They do squash bugs when they have good descriptions and can be reproduced reliably. That makes it possible to see, understand, debug, fix and confirm the fix. The release and patch cycles are a bit slow, but it is what it is at this point. 

     

    I have solved similar freezing issues before, but none were due to Delphi itself. Windows APIs tend to hang when trying to access non-existent network resources. Some old projects referenced common libraries on network shares on servers long gone but still in DNS. Strangest case was dead batteries in a RAID card which caused a Windows cluster to not use write caching - writes were only considered done when they hit the physical disks. Throughput dropped hilariously low for the hardware involved bottlenecking everything. That makes finding a freezing issue in Delphi itself harder without a way to reproduce as what a customer sees might not be due to Delphi itself. 

     

    Seems like a catch-22 at this point: the freezing robs time from the same people we need to spend time on troubleshooting and trying to find a test case. 

    • Like 1

  2. Far as I know an object's dependencies should come in through the Uses in its own unit file. You only need to add locally in the test unit anything you are using in your tests. 

     

    Quote

    add in the search path all the paths to all the files not in the project to be tested

    Is the "not" accurate? Makes no sense at all. 


  3. Without a way to reproduce it could be a lot of things. Seen code skip a step in a process when a debugger was attached that was added to speed up debug runs looking at latter steps. 

     

    Also, time the freeze - a consistent over X seconds can be helpful to indicate if it is a timeout like looking up a network name or trying to initiate a network connection to something that doesn't respond at all.


  4. I believe dbExpress is like the BDE - included/available but not really kept up to date at least regarding what is included with Delphi. That is why I suggested the DevArt drivers which have seen more development since the Delphi XE5 days when FireDac was introduced as a replacement to overcome the unidirectional nature of dbExpress.  

     

    See how dated the SQL Server version are in this list for example: dbExpress Supported Database Management Systems - RAD Studio (embarcadero.com)


  5. Could try a different dbExpress driver for SQL Server like the one from Developer Express (dbExpress Driver for SQL Server (devart.com)). Has a 30-day trial so can test it and then decide. 

     

    Note the Microsoft SQL Client(s) and versions can be a bit of a mess with 32bit and 64bit being separate and the names changing over the years. Make sure they are up to date and the correct 32 or 64 bit plus older clients are cleaned out.  


  6. Looks like "Lock Controls" in the Edit menu is an IDE wide setting that can be toggled on and off. However, it is bugged - the locked state is not applied to the design surfaces of forms created or opened after Lock Controls is toggled on - they have unlocked controls. This leaves us with a toggle that isn't consistently applied so users must toggle it off then back on to get it applied to all open forms. Same for opening a project - even with Lock Controls toggled on all forms are opened unlocked. 

     

    I created a new ticket for it. There are other related tickets, but none specifically target the failure to apply the current setting when loading/creating forms. 

    [RSP-42429] ON setting of Edit -> Lock Controls ignored by newly opened or created forms - Embarcadero Technologies

     


  7. For me 11.x series and 11.3 specifically has been a high point but for small reasons - like GetIt no longer being glacially slow bringing up the list of packages and the IDE having more polish / performance in my use of it. Just feels nicer to me subjectively. Some growing pains in the updated IDE and other features but they are, granted too slow for some, improving. 

     

    There are sometimes offers of discounts on longer maintenance periods and I took the bait last year on a 5-year renewal. 

     

    As usual a lot depends on how many third-party components need to be renewed / replaced to migrate to a newer Delphi if your current development environment has stayed static for a while. 

    • Like 2

  8. In C++ Builder you can import/use Delphi units inside a C++ project, so you don't have to convert everything to C++ to get started. C++ Builder is C++ along with bindings for the Delphi VCL and other units so you will be using a lot of Delphi code under the hood even if all your application code is converted to C++. 

     


  9. 18 hours ago, luciano_f said:

    Who knows, maybe the day Microsoft says it will end support for Win32 will see Embarcadero in shame.

    Application developers still using Delphi 1, which used Win16, will need to migrate to a newer Delphi version in the next two years if they want their applications to still run on a Home/Pro supported release of Windows. That release is Windows 10 32bit 22H2 which ends support on Oct 14, 2025. If on a Windows 10 Enterprise LTSC release that could be longer - LTSC 2019 has support until 2029. 

     

    I think Win32 32bit applications are safe for another couple of decades.  


  10. I think a 64-bit IDE would help uncover some bugs by throwing more and earlier memory access exceptions leading to a better IDE all around. The 32bit IDE ends up with so much of the address space occupied on large projects that bad memory references are left to cause random problems at random times. 

     

    Time to at least start work on a 64bit IDE.

    • Thanks 1

  11. Far as I know it is still with Code Partners where the product pages are excluded from being indexed by search engines so very few people will ever find it. It has amazed me for a while how a company can produce a product, sell it on the Internet but make it non-discoverable using search engines. Just checked and the product page ( SmartInspect – Code Partners (code-partners.com) ) still has:

     

    <meta name='robots' content='noindex, nofollow' />


  12. WinRT was "Windows" on ARM without the Win32 APIs but a new set of "Universal" (UWP) APIs. It Failed.

     

    The new attempt of Windows on ARM supports the same APIs as x86 and x64 builds for ARM binaries and emulation/execution of both 32 bit (with Windows 10) and 64 bit (with Windows 11) x86 binaries. It is not yet in general release. 

     

    IF Microsoft sticks with this iteration of Windows for/on ARM it could be good for Delphi as VCL applications would be possible both as x86/x64 binaries and once Embarcadero supports it, ARM binaries. Unfortunately the track record is poor and some caution is likely warranted before expending significant effort as Microsoft could switch to another track. 


  13. You would need to be a sadomasochist to trust Microsoft until such a platform is well established. Windows RT was over a decade ago and those who got sucked into developing for it wasted time and money. Even worse would be anybody who developed for the various incompatible iterations of Windows Phone. Also no rush as the small number of such devices sold supporting the new "Windows on ARM" attempt are able to run Win32 applications (x86 with Windows 10 and x86/x64 with Windows 11). 

    • Like 2

  14. The current layout of topic view leaves little space for names with a lot of them being shortened and a ... added. Happens a lot with those who use first and last names where both are not short. Makes it hard to follow some topics if contributors share first names or recognize some posters if a significant portion of the name gets cut off between Unread Content view and Topic View. 

     

    A fair number who post here use proper names including both first and last names which might make the issue more visible compared to the shorter handle/user style names used elsewhere. 


  15. Ubuntu 20.04 has libmysqlclient21 not the libmysqlclient20 on that linked webpage. Did you update the package install and link command to refer to 21 instead of 20 like shown below?

    sudo apt update
    sudo apt install libmysqlclient21
    sudo ln -s /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21 /usr/lib/x86_64-linux-gnu/libmysqlclient.so

     

    • Like 1

  16. I think coroutines are a dead end just like fibers in regards to performance. With pre-emptive multitasking the amount of work done before switching can be adjusted by the OS scheduler for the current hardware and execution environment. A system with a lot of CPUs with deep pipelines will perform better overall switching tasks less often than one with fewer CPUs and very shallow pipelines for example. 

     

    With coroutines/fibers the work division is basically fixed in the source code and even if optimal for one hardware and execution environment will likely be suboptimal in others. It is similar to the fixed instruction parallelism attempted with EPIC but in source code form as a language feature. Looks good at first but runs into problems. 

     

     


  17. 4 hours ago, limelect said:

    @Stano Can you plz tell me your fix? how did you debug it?

    Be aware that it is duplicate pages

    Hard to follow, can you explain how 0505444457 is considered a duplicate of 0509503671? 

     

    Showing the report design would help others see what you are doing and narrow down possible issues.  Or attach the .fr3 file instead of dumping it's contents in the text of a post.

     

    The band types chosen, their positions and the lack of linking between master and child look all wrong in your report - suggest working through some example reports and the documentation to get a feel for how they are used. 

    • Like 1
×