ULIK

Thanks, that indeed looks like the same error. And I wonder why it works with 1.3.8.50. Anyway, thank you for maintaining that fine tool!

Hi Uwe, as I'm started to use the dependency analyzer more often, I noticed a small bug on it: - it claims an error for some units because it does not find some INC files (UDA_1) - so I added the path to this file on it (UDA_2) - Now error is gone - Them close the project and reopen it - now the error is back on unit dependency analyzer and the path is no longer available on options (UDA_3) Not a big problem, just in case you have some spare time 😉 kind regards, Uli

Thank you, Uwe. It's up and running fine again!

Hi! I noticed a bug on MMX 14.0.4: working on Delphi 10.2.3 I can no longer open the unit dependencies dialog as this throws an access violation: command line : "C:\Program Files (x86)\Embarcadero\Studio\19.0\bin\bds.exe" -pDelphi executable : bds.exe current module : madExcept_.bpl exec. date/time : 2018-03-09 14:55 version : 25.0.29899.2631 compiled with : Delphi 10.2 Tokyo madExcept version : 4.0.21 callstack crc : $66537fdd, $000de4d0, $5b5c01d6 exception number : 1 exception class : EAccessViolation exception message : Zugriffsverletzung bei Adresse 208A1DF8 in Modul 'coreide250.bpl'. Lesen von Adresse 00000000. main thread ($1bcc): 208a1df8 +034 coreide250.bpl IDEServices 3095 +2 TIDEServices.ApplyTheme 20854e56 +042 coreide250.bpl OTADockableForm 105 +2 TOTADockForm.EmbedFrame 20854db1 +06d coreide250.bpl OTADockableForm 77 +6 TOTADockForm.Create 2085532e +08a coreide250.bpl OTADockableForm 234 +9 TOTADockableFormManager.CreateDockableForm 208a4fdd +005 coreide250.bpl IDEServices 4265 +0 TIDEServices.CreateDockableForm 5016dcd8 +004 rtl250.bpl System.Classes 16816 +0 TBasicActionLink.SetAction 21a259c9 +03d vclactnband250.bpl Vcl.ActnMenus 1079 +6 TCustomActionMenuBar.ExecAction 21a2727c +124 vclactnband250.bpl Vcl.ActnMenus 1850 +19 TCustomActionMenuBar.TrackMenu 21a2acb2 +042 vclactnband250.bpl Vcl.ActnMenus 3644 +5 TCustomActionMainMenuBar.TrackMenu 21a2557d +029 vclactnband250.bpl Vcl.ActnMenus 958 +3 TCustomActionMenuBar.CMItemClicked 50ae4c5e +2be vcl250.bpl Vcl.Controls 7338 +91 TControl.WndProc 50ae9843 +63b vcl250.bpl Vcl.Controls 10209 +166 TWinControl.WndProc 21a27392 +0aa vclactnband250.bpl Vcl.ActnMenus 1889 +25 TCustomActionMenuBar.WndProc 50ae8e10 +02c vcl250.bpl Vcl.Controls 9908 +3 TWinControl.MainWndProc 5016ebcc +01c rtl250.bpl System.Classes 17408 +11 StdWndProc 75657885 +00a USER32.dll DispatchMessageW 50c31e1f +0f3 vcl250.bpl Vcl.Forms 10641 +23 TApplication.ProcessMessage 50c31e62 +00a vcl250.bpl Vcl.Forms 10671 +1 TApplication.HandleMessage 50c32195 +0c9 vcl250.bpl Vcl.Forms 10809 +26 TApplication.Run 7635343b +010 kernel32.dll BaseThreadInitThunk I checked it again with MMX 13.1 and here the dialog opens fine again. If it is related: IDE designs are deactivated on my Delphi installations. kind regards, Ulrich

Don't worry. It's fine to test against the defaults only. For all the special situations we have that group here to post the problems

I've done a test: if I enable IDE designs, then it is working again with 14.0.4. But it would be fine, if you find time to fix this (I prefer to disable the designs ,as on Windows 7 I find this better readable) Thank you, Ulrich

That's much better! Thank you for fixing this and doing all the work on Code Explorer.

Hi Uwe, just installed latest version 14.0.3 on Delphi 10.2.3: now it looks like some keyboard shortcuts are no longer working: Ctrl + L to declare a new local variable or Shift+Alt+up/down to move selection up/down. It simple does nothing (Ctrl+L) or is doing a block selection. After reinstalling 13.1.0.2220 keyboard shortcuts are working fine again.

Just an idea: check the code for cxPropStore on TFormEdAnlagen.FormClose as well as TFormEdTeil.FormClose . It is explicitly activated which should automatically save the properties on form close but then you also manually save them. Do you also get the error when you do not activate it (or remove the entire cxpropstore code) ? Maybe the explicitly activating triggers some recreation of controls. Also I would test if removing BarManager.BeginUpdate; ... BarManager.EndUpdate; on the FormClose procedures makes a difference (if I remember right, BarManager.EndUpdate triggers at leats a repaint of the controls but maybe also a recreation). And I don't think that storing the settings requires an enclosure with BeginUpdate...EndUpdate) kind regards, Ulrich