Günther Schoch

OK - added the bug report RSS-3157

@All Thank you all for the interesting feedback. In the meantime I tried to get a "first opinion by embt" as well. Depending on that answer, I will raise then the necessary report(s) and link the number(s).

Hi while testing a Delphi syntax parser, we struggled over a few line in the Delphi "Winapi.ShellAPI" interface. In opposite to 99.99% of similar declarations, 3 lines have no semicolon at the end function SHLoadNonloadedIconOverlayIdentifiers; external shell32 name 'SHLoadNonloadedIconOverlayIdentifiers'; function SHQueryRecycleBin; external shell32 name 'SHQueryRecycleBinW' function SHQueryRecycleBinA; external shell32 name 'SHQueryRecycleBinA' function SHQueryRecycleBinW; external shell32 name 'SHQueryRecycleBinW' function SHQueryUserNotificationState; external shell32 name 'SHQueryUserNotificationState' delayed; the 3 lines in the middle have no ending ';' (lines 1825 - 1827 for delphi 12.2). Is this really a valid Delphi syntax or just a glitch in the compiler?

Hi I managed to register an own extension to the IDE. My Plugin Component does register var edtServices := (BorlandIDEServices as IOTAEditorServices); var locMenu:= edtServices.GetEditorLocalMenu; FActList:= TActionList.Create(nil); FAct:= TAction.Create(nil); FAct.OnUpdate:= OnUpdate; FAct.OnExecute:= OnExecute; FAct.Enabled:= True; FAct.Caption:= 'My Ext'; FAct.ActionList:= FActList; locMenu.RegisterActionList(FActList, cEdMenuCatLast, ''); but the documentation does say that I shall unregister as well var edtServices := (BorlandIDEServices as IOTAEditorServices); var locMenu:= edtServices.GetEditorLocalMenu; locMenu.UnregisterActionList(cEdMenuCatLast); FActList.Free; Question: looks as there can only register exactly 1 plugin per Editor Menu Category? What if 2 plugins try the same?!?

Hi I thought it make sense to share the link to our discussion on that topic in the TestComplete forum. https://community.smartbear.com/discussions/testcomplete-questions/delphi-12-x-officially-unsupported/267672 Well, I know that a lot is not properly running (e.g. VCL Styles). But until now, we were still able to run our large number of test cases. But after dropping AQTime, now SmartBear silently drops the Delphi support for TestComplete as well. TBO, the new SmartBear subscription model is far too expensive compare with our last 3 year renewals. And we do normally not use any software on "rental base" that stops suddenly. But transferring all the tests to something "new" is a nightmare ... somehow a deadlock again. regards Günther

For such critical bugs company as EMBT has to communicate openly on the status: - what is reproduced - where exactly is the problem (use cases affected) - status of the fix - open program to participate on the BETA of the hotfix - etc All that give a real bad feeling that the developer team is somehow guessing around what change had what influence ... Perhaps we should start a open petition https://www.change.org/start-a-petition?source_location=header that we are as "developers discriminated" by EMBT as our rights to know when critical bugs get fixed is ignored.

most probably interconnected. If the compiler fails randomly with an internal error then the LSP fails as well randomly (as LSP does interacts with the dcc.dll)!

well - but 10.4.2 is not working for larger projects. EMBT has solved that independently of any roadmap.

the instabilities of 10.4.2 are just wasting the work time of many developers. Our company has decided to not use 10.4.2 until there is a patch available (well more likely a 10.4.3 as the IDE will most probably change as well). Not sure what is needed (see https://quality.embarcadero.com/browse/RSP-32768 and other 10.4.2 bugs) to get a) a statement by EMBT that we see one, two or n independent issues b) a scheduling of the patch by EMBT c) a small BETA for the companies seeing that problem(s) to really crosscheck that it's gone. But the situation today is a full "deadlock". We should go to 10.4.2 for other issues that are solved (e.g. LSP, VCLs etc). But we cannot shift as the version fails for larger projects.

to be precise it should be the same issue as https://quality.embarcadero.com/browse/RSP-30588 but DelphiLSP has as well other known issues as https://quality.embarcadero.com/browse/RSP-30627 https://quality.embarcadero.com/browse/RSP-30667 (EMBT is aware of the issues that were already raised during the BETA)

Exactly - Comes back to my initial subject of this thread "are we just cash cows". Promising and selling something is OK. But the necessary R&D resources (including a real test team) are the consequences. Otherwise I could start to sell "travels to the Mars" with upfront payment.

For the mobile area more resources would be essential. We actually never used FMX for production as we considered the delay of supporting platforms as too risky. The VCL side ... well, getting better but still smaller issues. But my main concern is the language itself, the compiler(s) and the testing. IMO for all these aspects additional development resources are essential.

Hello Lars, I accept that you see it as FUD. And you have to accept that I cannot say more here. But we can turn the question and say: - if Delphi does not earn enough money to make the R&D speed and quality "acceptable" then it's dead anyway - if Delphi does earn enough money to make the R&D speed and quality "acceptable" then the money is spent probably somewhere else.

Hi Kas, I understand your frustration as after all you love Delphi and would like it to have a future. But I really want to avoid a general bashing. That will not change anything for the future. I am pretty sure that today some developments (e.g. RadServer) would not be started anymore. But the purpose of my thread here was "how to semi-softly push Embarcadero to deliver something in time for the money we pay in the "software assurance". And I argued that they need to use more of the income for R&D to change something.

Ask EMBT directly if that statement is not true. I cannot share more. But assume 15-20% R&D.