-
Content Count
35 -
Joined
-
Last visited
-
Days Won
3
Günther Schoch last won the day on July 15 2020
Günther Schoch had the most liked content!
Community Reputation
61 ExcellentRecent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
TestComplete - Delphi 12.x officially unsupported?
Günther Schoch posted a topic in Software Testing and Quality Assurance
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 -
Several F2084 Internal Error on Delphi 10.4.2
Günther Schoch replied to Davide Angeli's topic in Delphi IDE and APIs
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. -
Several F2084 Internal Error on Delphi 10.4.2
Günther Schoch replied to Davide Angeli's topic in Delphi IDE and APIs
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)! -
Several F2084 Internal Error on Delphi 10.4.2
Günther Schoch replied to Davide Angeli's topic in Delphi IDE and APIs
well - but 10.4.2 is not working for larger projects. EMBT has solved that independently of any roadmap. -
Several F2084 Internal Error on Delphi 10.4.2
Günther Schoch replied to Davide Angeli's topic in Delphi IDE and APIs
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. -
Right click -> Find Declaration, doesn't work most of the time
Günther Schoch replied to ioan's topic in Delphi IDE and APIs
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.
-
We all know that it still takes some time (at least based on all the open serious issues). But my topic was to change something for the future. I am sure that Marco and the team is clever enough to solve a lot more problems and enhance the product if they get more money (very simple calculation). But the money is "used" elsewhere and this should change.
-
we are in the same deadlock. But I think we all pay the software renewals exactly to "not end in this situation".
-
Dear Delphi developers, first of all, I do not want to have any "Delphi Development Team" bashing here. I just try to summarize the current big picture and show the dilemma. Not going to much into details, the today status of 10.4 is: 10.4 went clearly into the right direction the development team is highly motivated and shares information the development team is open to arguments and suggestions of the community Why I am not really happy? a lot of issues have to be fixed (which are BETA level but should not be in a final product) fixing takes several n-months using the full resources until then 10.4 cannot be considered fully productive Macro, Bruneau, Dmitry etc, … they all know the problems and work really hard. The performance of the team is great but the output limited I cannot agree with the argument that 10.4 had too many new features. It's more the minimum to survive new basic strategic developments (modern language elements, compiler optimization, etc) not even started The real problem is that the resources are far too small for the real-world challenges of a full development environment. Why is that the case? Are the sales to small? (I would say no) Is the percentage of reinvestment into R&D just too small? (I would say yes) The numbers under https://medium.com/@sammyabdullah/successful-saas-companies-spend-23-of-revenue-on-r-d-3602e9dc2de are rather interesting (marketing driven versus technology driven companies). But what does the Embarcadero management and owners think, given these private equity companies bought Idera/Embarcadero for some crazy amount of money? As long as the sales (software renewals) are still flowing … why should they invest more? This means we come to the cynical conclusion that paying "as long as we pay the software renewals, no additional R&D resources will be hired". But If we do not pay anymore then they just freeze the product?! Ideally there should be a contract form that assures "software renewals go for 50% into R&D". Why? No-more marketing is needed. The renewal is (should be) a fully automatic process without large handling costs. Not easy! regards Günther
-
Experience/opinions on FastMM5
Günther Schoch replied to Leif Uneus's topic in RTL and Delphi Object Pascal
Hi under FastMM5 you can switch all the reporting functions during runtime (no compile switches) Please have a look under FastMM_ApplyLegacyConditionalDefines you can use {$ifdef EnableMemoryLeakReporting} and {$ifdef RequireDebuggerPresenceForLeakReporting} or switch directly in you app I personally changed the behavior FastMM_ApplyLegacyConditionalDefines to fit to my "default" behavior = when debugging then always show leaks.