Jump to content

Bill Meyer

Members
  • Content Count

    656
  • Joined

  • Last visited

  • Days Won

    12

Posts posted by Bill Meyer


  1. 41 minutes ago, Uwe Raabe said:

    I encourage everyone to eliminate those cycles as soon as possible. They cost you a huge amount of your time.

    I agree completely. That said, they require significant work to remove. And though MMX can present reports on the problem, I am still looking for anything which can simplify the task of identifying the worst offenders. (Yes, it matters, as the full report is a bit overwhelming in this case.)


  2. 18 hours ago, Erix A. said:

    - IDE is slower than 10.2.3. For example, you can see how Project/Options window is being drawn while opening. 
    - If you set the dark mode, then you can see how options window is first drawn white and then skinned.
    - Code scrolling in the editor seems bit slower.
    - When app is run and the closed, lots of windows resizing, flickering is going on while the IDE goes from Debug to Default layout. (The same is happening in 10.2.3 as well, only it does it much faster).
    - Sometimes after couple of runs Object inspector is not drawn at all until you refresh it.
    - 1st full recompile of the project took about 12 seconds
    - 2nd full recompile 40 seconds
    - 3rd full recompile minute and something
    - 4th one is still running (joke)
    - After couple of recompiles, the whole IDE just blurs in the background, compiler gets stuck, and then after some time everything resumes.
    - Code completion still isn't working in my project (It works after the 1st compile, then stops until project is cleaned). I reported it to QC and even got some response in the item, but then it stopped. 

     

    When I turned the skinning off, IDE become more responsive, but some of the tool bars are drawn with non default background and when I hover over the tool bar buttons, the background for them becomes black.

     

    I'm kinda sad. Usually I install the new Delphi and very soon uninstall the previous one, as the new one is just better. Not this time 😞

    Your opening comment is very disappointing, given that my first impression of 10.2.3 is that the IDE is slow and flickers obnoxiously.

    I'm not a fan of themes, so the "solution" is one I can welcome. Is the IDE now perhaps all done with DevExpress controls with skinning? (Just asking...)

    Successively longer compile times is another disappointment, but having spent weeks now in moving legacy code into XE7 -- where it cannot build, except through the external build process -- has mad me much more sensitive to the numerous defects in the IDE. And I have turned off almost everything that in interactive in the IDE, in the hope of reducing the problem.

     

    I will mention, however, that some of your comments lead me to wonder whether your project is free of unit dependency cycles. Mine is not, and I know too well that those cycles lead to many problems. The "stuck" compiler is one of the symptoms I have seen. 


  3. 1 hour ago, David Schwartz said:

    It doesn't work now. It generates a run-time error. Did you read my original post?

     

    I'm getting "invalid type cast". It's in GetIt250.bpl, and apparently others are as well. And there does not seem to be any workaround other than going back to an earlier version.

    Yes, I read your original post. So as I understand it, then, the problem with GetIt makes Tokyo unusable?

     

    I did have a similar problem with Tokyo in a VM a couple of months ago. Did the uninstall/reinstall dance, and then it worked. I have my own concerns about Tokyo, but GetIt is not chief among them. That is why I asked.


  4. Quite a few years ago, Jack Crenshaw wrote a series of articles on how to build a simple compiler. He wrote in TP, and develops the whole thing step by step. It is a recursive descent compiler, and originally emitted assembly code for a Motorola 68000. The articles have been further developed over the years, and the target altered to the 80x86. The value is simply that he wrote this for people who are not writing a compiler professionally, but who wish to learn the mechanics of compiling code. The writing is clear, and the whole development easy to follow. The articles can be found here:

    http://www.pp4s.co.uk/main/tu-trans-comp-jc-intro.html

     

    • Thanks 1

  5. 3 hours ago, KodeZwerg said:

    Does the code not work?

    Which code? You posted code for use in a package. I am now scanning the registry, and collecting from there with my own code, which works fine, though there are a few idiosyncrasies in the lists there.

     

    The  point of my last post, though, was that although the registry scan is convenient, it is specific right now to XE7. And given the minor irregularities I have found in the entries there, it seems reasonable to anticipate irregularities in other versions, whether the same or different to these. In D2007, however, I find no evidence of installed components in the registry, so in the end, the ToolsAPI may be the only reliable approach.


  6. On 11/16/2018 at 4:16 PM, Uwe Raabe said:

    You can also search the registry. The Package Cache key (like HKEY_CURRENT_USER\Software\Embarcadero\BDS\19.0\Package Cache) contains all installed packages with all its components.

    As it happens, I need to run in XE7, where the key is this: HKEY_CURRENT_USER\Software\Embarcadero\BDS\15.0\ToolForm\Mapping. I also have an interest, though no absolute need, to run this in D2007, but I find no entry in the registry for such information. Has anyone committed a web page on the variations of such content in different versions?


  7. In the course of some project analysis, it has become apparent that we would benefit from exporting a list of all installed components in Delphi. I have found articles discussing how to obtain the list using the ToolsAPI, but that would mean building a package for a wizard, which is more of a side project than I was seeking.

     

    If anyone knows of an existing wizard which would provide the functionality, I would appreciate a lead.

     

    Bill


  8. Looks nice! Now, on a more serious note, I am dragging a very large app forward in time (from D2007), and trying also to untangle snarls of legacy sins. Bringing code into XE7 has been a necessary first step, and has shown me just how easily the IDE's internal systems can be compromised. Killing and restarting the IDE a few times an hour is annoying. So are the Out of Memory error. I freely grant that many issues are caused by poorly written code, but the rework can only be accomplished if a stable environment is available. 

    One example is the minor editing of an interface uses clause which all by itself provoked a rising memory burden until it was necessary to kill and restart. In a few cases, I found it easier to simply use Notepad++ to edit the file, and then reopen in Delphi.

    All versions work fine on small apps. But large apps filled with legacy code are an everyday reality.


  9. Good info. I am on the verge of tangling with that beast, and am glad I won't have to find my way to that approach on my own. 

     

    I know  the DevExpress components are well liked, but I find a good deal of their stuff to be overly complex. And the documentation seems only to be reference material, not introductory and tutorial. Facing a 4,500 page reference manual is a lot like having no docs at all.

×