Leaderboard

Hi Dominique, Thank you for your feedback. I value your input here and I will try to address your concerns below. I understand your disappointment regarding our current development speed and release times. As I've always said, the development speed for uniGUI has never been constant. It can be quite fast at times or slow at other times. However, it is obvious that we have failed to keep up with the release dates announced in the latest roadmap. Again, roadmaps are not contracts. They're announced to let people know what is about to come in near future. There can be deviations from the roadmaps. We've succeeded to complete up to 80% of items in the 2019 roadmap. Without doubt the remaining 20% are very important items, including infinite grids, Linux and responsiveness support. The "light releases" that you have mentioned above are being released for past two months, that is correct. However, it is not true for the whole 2019. Year 2019 as a whole, is/was a very productive year for uniGUI. In this year many bugs have been fixed and many new features have been added. Please don't be disappointed simply because for our bad performance which can be counted only for past couple of months. A release interval of every three weeks seems to be OK from my point of view as long as each release addresses enough issues. That said, this situation will not stay the same. We are committed to the 2019 roadmap. All of the announced features in the roadmap will be implemented unless we state otherwise or revise the roadmap. We don't have any intention to revise the current roadmap. That said, obviously the dates in the roadmap need to be revised and shifted for a few months. While your views on current status of uniGUI are fully valid and understandable, I don't understand why you need to mention about a competitor here. First of all, comparing uniGUI to TMS Web Core is comparing apples to oranges. What makes uniGUI powerful is its server side integration with Delphi. It allows a seamless integration between Sencha Ext JS and Delphi. It will be a futile effort to try to explain what uniGUI is and what it can do, because all of you are already quite familiar with uniGUI. On the other hand, client side only web frameworks such as TMS Web Core adopt a totally different approach. The pseudo Pascal language they use can mimic Delphi language, but the whole environment is far from being Delphi! Delphi is not only about Pascal language. Delphi is about Object Pascal, database integration, third party tools and data aware components. Can you tell me to what level TMS allows to integrate your app with databases? You have complained about issues with DBLookupCombo, but do you have something similar in TMS Web? OK. I don't like to criticize other frameworks. I believe that all attempts to create 3rd party tools for Delphi are priceless and I wish success for all of them. However, TMS Web Core doesn't seem to belong to Delphi eco-system other than it's Pascal language. Someone can move away from Delphi Eco-system for several reasons. That happens all the time for various reasons, but many also decide to stay with Delphi for other uncountable reasons. For same reasons people choose uniGUI over other tools. 1) Maintaining Delphi licenses may cost you a few thousands annually. It can be pricey, I agree! As I told above, as soon as you decide to leave Delphi behind, there are many alternatives out there. TMS Web would be only one of them. Question here is that are you ready to loose all those benefits brought to you by Delphi and its eco-system? Maintaing Delphi can be expensive, but it can also save you from hiring more developers which can save you much more! It is not really about uniGUI, but about Delphi and its surrounding eco-system. 2) Good, but where is the original product named Delphi for PHP now? From what I know it is no longer around. 3) Free is not always free, especially when your time costs money $$$! 4) OK sounds good, but doesn't mean that you'll be more productive. 5) It's nice feature. Something that we also consider for the future. 6) It's a bit tricky. We were able to show data at design time since uniGUI 0.1 directly from a db table. However, when it comes to REST services, you need to create/configure one beforehand to be able to consume it in a designer. In my view, Delphi's data handling capabilities are still matchless. 7) If your app is so simple that you don't need a server, yes. Otherwise, you need to run a server for your database back-end and etc. 8) It is partly true for client side only sessions. But even for a minimal database work you need to extend your sessions to the server side. Which will complicate things even further. Your REST server will know nothing about your sessions. You must implement your server side session logic. 9) How about Delphi's existing 3rd party components? Such as reporting tools? 10) Already resolved in Ext JS. 11) Yes, you should also list the down sides. I have not fully reviewed the product, but I can mention some points here: You will not be able to use Delphi, its rich language, 3rd party libs and its powerful data aware components. Your code will run in client's browser which means your business logic will be exposed to outside world. What if your app is very big? I've seen uniGUI apps with hundreds of forms and data modules. How can such giant apps be loaded and run on client side? Almost all business web apps rely on heavy data consumption and manipulation. In this case you need to develop your server side business logic separately in a different tool and integrate it with your client web app. Consider that you have too many data tables on your server side. For each table these tasks should be repeated. Needless to say how these tasks are easily done in Delphi. In uniGUI you develop one application. You don't need to care about server side separately. Getting data from a REST server can be easy, but posting back, modifying specific rows, running complex queries can make your life harder than you can imagine. If you need computing power in your app, you will be limited to client browser CPU power. Since it is not native code your code will never run as fast as native CPU code. Don't forget that your code is translated into java script. On the other hand, servers are equipped with plenty of CPU cores, computing power and gigabytes of RAM. Since code runs in client browser. Your debugging and logging capabilities will be limited compared to server side code. OK. I'm not an expert in Web Core or similar frameworks. I'm not here to discredit their product. I wish them success, as I'm sure many people will find this kind of web development useful. What I'm trying to say here is that Web Core or similar frameworks can not be a replacement for uniGUI because they are not in same category with uniGUI. You can save that money today by simply switching to ASP.NET. I am here, but you are correct that I was mainly silent on the forums. I'm sorry for this. But "this" is not the "same" thing... The shown demo is a very very simple app. Not even an app. We need to see something more complicated, comparable to the simplest business web app that you can develop with uniGUI. Let me state again, through 10 years of my uniGUI endeavor I have never said a single negative word about competitor frameworks. We are busy with our own tasks not other people's stuff! The only reason that I made above comparison was that you have mentioned it here. Back to our own reality. We will be back to our full development speed soon. To compensate our deviation from roadmap I will extend all subscription dates for at least two months. I will further extend those dates if needed in the future. If we have failed to address any urgent bug, long awaited issue or question please go here. We will analyze your request and if we find your request acceptable then it will go to top of our to do list. Best regards, Farshad

Can you check this? UniTagField.rar

Hi, this create a Memory leak. Delphi :XE2 update 4 UniGui : Rel 1401