MichaelT

Did you visit David I. 😉 Connect all the 6 boxes, since everything is connected with everything else and all problems are gone. I doubt that will work. pgAdmin works great in virtual-boxes, especially because of the dashboard and debugging against a run-time environment on the server works great but only if just the screen is sent to the client. Forget it. I tend to agree that in both cases Delphi and Python a solid well maintained base for C-Bindings attracted people. Think of project Jedi but a Windows origin and the integrate everything into the desktop and the Explorer strategy put another level of complexity on top, which lead to anything but simplicity in the end. Apart from that, you talk about something totally different than Delphi. Not sure if a Delphi like way is an answer to the underlying questions accepted by a broader audience. Elevate Web Builder would be a first step into such a direction once debugging on the client side is possible, but even that is not really required at the moment. Without proprietary add-ons in general integrated functionality is hard to achieve. It's 25 years too late for 4GL love. There is no such thing as an open let's say ABAP-stack just for the Web. Sounds like that. You want something pretty similar like the SAP-GUI called Delphi-GUI. I worked on/with something that was called XSTP-GUI which integrated Java widgets in the mid/late 1990s and an approach that work like a charm on Smalltalk-System put to the next level on Java busted with flying colors. Javascript is about portability and from this perspective an integrated IDE like Delphi is a meta tool allowing to build the environment you suggest. The more features you add to the very definition of an IDE, an advanced editor with a menu entry called tools supporting invoking them in the context of the IDE adds interfaces (common sense) to other disciplines of software engineering who do not even care a tiny rabbit shit about you and your IDE. The last revival into such a direction, which inevitably comes with your suggestions outside the scope of what an IDE is meant to be, I have seen in the fashion of add-ons to the Eclipse IDE which again failed to succeed even on a mid term, because of breaking changes in the Eclipse IDE itself. Do you really that all the others have to put things in the right place at the right time just because you want to press a button and everything works as intended by you 😉. Maybe it's the biggest tragedy for the Delphi super-hero that the world never worked this way and rest assured it never will. The Delphi world is about succeeding in a dynamic environment where anarchy still matters and rulez from time to time or all the time and not about a consensus on praising others for leaving things unchanged. I tend to agree that developing in another environment but the target environment makes development pretty complicated. Going beyond an IDE based approach leads to to something beyond pretty quickly a workbench for example or many of the 1990s approaches that worked pretty great generating C Code and indeed they were abandoned for the wrong reason 'C', which was heavily bashed these days. All that came later used a virtual machine especially because of being in the position to utilize dictionaries in case of the CRM-systems (integrated development and execution environments) or RTTI exposed (JVM, .net runtime, ....). It's not surprise that those who never worked with e.g. Smalltalk before tried a revival but on another technology called Java oder .net and spent their time wasting to again rebuild all the crap people threw out of the windows when XP-programming was introduced including their managers and the bureaucrats. Kidding. Even if the IDEs dominated the scenes for along time theirs has come when it comes to software-development. I see no way why an integrated tool should give the answer. You should not assume that an application is what people want. People got used to it. Except from the very early versions Borland turned Delphi, said more precisely Turbo Pascal, into a Y2K child. I didn't have the impression that Y2K was a challenge for small shops in a first place. Everyone asked for Business-software on Windows. So it's no surprise that Delphi turned into what it is today. It's just not that bad. EMBT successfully had enough to do with putting the Wild West style mess we left from 1997 to 2005 into a somehow consistent no one knows how what it's good for today. The 1990s were about making money and not software-engineering since it turned out soon that the whole bunch of software methodologies and other failed approaches allowed to kill budgets. After the these days were finally gone with the disappearance of Windows XP the honst soles were left back what without them could be called a ghost-town. But what those who disappeared behind the horizon after a tough ride were the requirements for what is called FMX today and EMB had to live with that situation. In both cases the question of in how far an IDE based approach is the answer to both love in the very detail and a total open approach attracting developers beyond what's already available. If you remember what was the answer to performance, a) buy a new Windows and a new computer b) let the database do the calculation jobs or use extensive profiling and c) use assembler.

That's one just for the German government. The small-footprint(f) *) light-weight databases made/make lots of sense in environments where people managed(ed) infrastructure on their own. There is a use case in the steel works of my hometown. As a result of a problem in a plant the whole cabling including those related to the IT network melted. The multi-user application for a small group of about five people from the team responsible for repairs just drove the data-center, took the files and put them on a local share in an office within the plant to a local server. The Inventory system was required because one or two hours later about 200 to 400 people started the repairs and needed lots of materials and so on. This application didn't rely on Absolute DB, they relied on the other solution whose name I've already forgotten but you you know which one I mean. In several scenarios some features worked pretty fast. 'A better in-memory table covering multi-user scenarios' is not a bad choice but don't expect it to be a page oriented DB server. You should know better. In general for about 10 years know the demand for those seemingly 'esoteric' solutions has been shrinking radically. Honestly why not choose a different database from what anyone else uses? Hey. It's Delphi! Why bother with the 21st century, doesn't look that great until today anyway, when you can still program as if both Kurt Cobain as well as Elvis were still alive kicking. Kidding. As long as no one else but you or your application are fiddling with the data such solutions do their job pretty well. What I'm wondering is if ARM processors would give such plug-able persistence interface solutions a push. That's why I never really understood why EMB(T) didn't offer an ARM compiler outside iOS or Android an a minimalist frameworks allowing people to just port non visual stuff. I love such things. TurboDB, Apollo, Vista DB (.net only I think today), NexusDB, ElevateDB and so on are still great. Also here, except form niche scenarios people simply put their IT to a data-center and 'forget the crap'.

The integrated everything integrated into an application with simplicity in mind is a Windows thing. No matter how you define alternative to SQLite the question is to whom does an application matter on a platform. In case of Linux I tend to think absolutely no one. Consider that most people tend to prefer something like small-foot print or light-weighted daemon based server rather than having to move a way from their SQL capabilities gathered over the years once being in the position to query data on their own is a must. That didn't change ever since SQL was introduced. Remember Access. Integration into the surrounding eco-systems of tools, backup/restore/repair and compatibility with tools and if a programming language is involved a certain kind of debugging facility. In order to get an impression if 'such a' database fits your purposes you will have to give it a try first. Don't trust any benchmark you didn't fake on your own. Usually all these so called hidden champions do their job surprisingly well. Have a look at blobs and encryption for example. All the well known alternatives of this kind of databases do their job pretty well and some of them are surprisingly performant. The Windows style of doing things is pretty different from the Unix/Linux style of doing things and Delphi style of doing things differ a lot more from the Windows style of doing so. Honestly I don't remember AbsoluteDB in particular. Today I think most DB solutions of these kind do their job pretty well.

No need to investigate anymore. That happens, if GExperts is installed. Removed Gexperts. If I dock the Code Explorer everything seems to be fine. In the undocked case only the panel with the inheritance hierarchy stays collapsed, but that's just normal. Sorry for that and causing work. The last time I had Gexperts installed must have been about 12 years ago or longer and I just wanted to take a look.

This behavior is not intended? Ok. Let me know if I can assist you.

That's an 'horrible' issue since it happens every time a file at cursor is opened (Ctrl + Enter) in both Delphi 10.3.2 and 10.4.1 here too. The MMX Explorer window disappears. If the MMX Explorer Window was docked before that empty tab somehow survives hidden and nothing shows up. What shows up is a message that an invisible window cannot be hidden (the usual well known dialog box) and right mouse click offers a context menu with (.... _ hide) shows up. Maybe all parts of the MMX Explorer window are hidden. In that case undocking an dragging the MMX Explorer window away from a position inside the IDE to the outside makes the tab disappear and afterwards I can open the MMX-Explorer window again. For me it works if the MMX Explorer window remains undocked (in practice right beside the IDE on the left side) and I can 'recall' the MMX Explorer window via a shortcut (Ctrl + Shift + Ä) in my case. The drawback is that the panel with class hierarchy stays closed (slider to slider), if a file was opened in the IDE in the meanwhile and MMX Explorer had no opportunity to recognize it before (new in the 'buffer'). If the MMX Explorer window is docked and the Desktop/Layout saved the situation improves, but opening a file at cursor leads to an empty panel displayed where the class hierarchy should be found in the MMX Explorer windows (latest version). In general saving the position of the MMX Explorer window helped in the past and still does. I fairly use MMX Explorer so that's not an issue for me. I can just say the problem described the line above does not happen if I 'recall' the window. You cannot have both. Docked an undocked. The moment a file at cursor is opened the undocked window disappears first and show up docked as defined in the Layout/Desktop in use. The 'issues' still persists no matter what version of MMX or Delphi after 10.3.2 I gave a try. I just had a look at the state of the MMX today. GUI looks great but I usually do make excessive use of Ctrl+Enter. That's why I usually make almost no use of the MMX Explorer. I didn't use many of the great features offered and if not in depth. I just used the MMX Explorer windows as an alternative to the structure pane/view, which does it's job too for such a limited purpose. What did improve definitely since you have taken over MMX Explorer, is the stability of the MMX Explorer if used undocked and from a first look it's also still stable (less error prone) in general, better said a lot more stable than in the past. Well done. Just came across this posting and thought I let you know, if the one or the the other behavior turns out to be an unexpected one. Fiinally I have to confess that I failed to comprehend the mysteries of the MMX Explorer in the very detail until today.

As mentioned above, the reply meant 'Use PHP'. The Delphi Web Server Application works pretty well but there are some influential factors e.g. having total control over the hosting environment. Usually those environment do offer the LAMP stack. There have been many attempts to host FAST-CGI server these days mostly written in FPC/Lazarus but from the hosting perspective PHP still rules and PHP engine handles the DB session management for you in a transparent fashion and not just this, what you would have implement on your own. Even if you implemented all the greatness the question remain, where to put all the stuff. Assuming you have full control over the hosting environment a web application is pretty different since the way a web application is treated by the server and the browser is pretty different from structuring an application via the hierarchic model introduced with the help of modules in general. The only exceptions, not even that pays, would be a 1:1 mapping of Screens to 'web-screens' or web pages that reflect a 1:1 or 1:m relationship of database tables or results taken from a data-service provided on your own implemented in Delphi technology, not talking about web-services and such things. Think of a 'main' web-module hosted in the web-server that is loading other modules ins fashion of a DLL or shared library on demand. All the goodness you implement would very likely be hosted this 'main' web-module that it plugged right into the web server. Anything else leads to a big module that contains everything. In comparison to a script based 'application' the module has to be unloaded or the web-server instance shut-down. In case of an Intranet-application feel free to give a Delphi Web Server Application a try. Take care of the 'Debug Spawned Processes' under Options -Debugger Options - Embarcadero Debuggers. In order to get an impression simply try and don't forget to host the web-module integrated before debugging (Run - Load Process). In worst case simply attach to a running instance. If you like it should still be possible to use the Abyss webs-erver again but therefore remove the Line that enables multi-threading in the program file of the ISAPI.dll, if I remember correctly. Under IIS or IIS-Express you can leave it unchanged. I don't have the source code at hand at the moment. Of course feel free to implement a Delphi Web Server Application and deploy a DLL to ISS or an Apache Module simply use any of the samples on the Internet. You will have to gain a deep understanding of the web-technologies pretty similar to getting to know Windows programming in order to provide something beyond that just works great for you. There are good applications put to the web server that did benefit a long time from being offered better floating point performance compared to PHP which was pretty similar to most web languages great at handling strings in a 'fast' way. The moment you had to add something to the PHP environment that relied on C/C++ code beyond the Delphi option started to gain ground also from the perspective mentioned in the first paragraph, ok, the second concerning hosting driven influential factors. For example presenting interactive CAD drawings can make sense, a few nice pictures and that's it won't pay that much. If you already gained a deep understanding of web-development already before, you would very likely not have asked, except you are forced to write an add-on module for an application. From the aforementioned perspective that overall effort can stay limited. I personally used Delphi web technology to retrieve structured data and built web-services like data modules a few years ago, at the time before JSON hyped and put the service behind a service-proxy in order to treat the various requirements concerning data presentation. If you start from scratch use PHP or Instant-FPC which combines the best of both worlds scripting as well as complied executables. In practice both alternatives will look pretty much the same, the moment the focus of the pages move a away from definitely a solid application put to the Intranet to strongly document oriented web pages/sites. As always on the web, 'it depends' and if you don't know the answer before, use PHP. That's very likely the simple reason why people advised you to give a LAMP or WAMP stack a try. Assuming you are hungry for implementing session management towards the data-base, alternatively use data modules Using Data Modules, I doubt you don't think of using CGI still, btw. I do, and you can rely on solid Delphi knowledge, simply start a module based Delphi Web Server Application and anything else is plain Request/Response. The web broker handles most of the communication. You won't get far beyond ASP & friends or Request/Response. There are many other options for using Delphi together with things built on top or replacing web-broker technology, but discussing those won't help, since they are all pretty good at what they are designed for.

How dare you! (That's for the young people here) David is what we call here, and very likely all around the world people call such guys, a K&R C beast from head to toe. David is still missing the 'Link with errors' feature to get his projects finished. I heard worse tongues whispering behind his back, that his Delphi programs consist of just one function starting with the keyword asm returning an invalid pointer to a corrupted heap or null/NIL to the command-line. In general I think he is one of the most advanced Delphi programmers visible and commenting in public on a regular basis, thus spreading wisdom and sophisticated knowledge all across the developer world. Let us enjoy his presence and listen to his words. Needless to say, since Nick turned on UAC on his PC almost nothing left to complain about remained. He's right, but on a contrary in IT a world that just sold it's future just around the corner the day before yesterday the difference betreen miles ahead or miles away is a pretty slight.

We are not the Cash Cows, that's Delphi. We are the goats to be milked. Reminds me of a story in my childhood in which a goat used to complain, 'I only jumped over grass and didn't find a single leaf'. Maybe at least another one in this forum who read the same stories or fairy tales in the child hood and nowadays as well on EMB flyers ... Pretty much the same issue with COM/ActiveX/COM+ support in the 1990s. Delphi went beyond what VB was in the position to offer but pretty 'late' in comparison what C/C++ offered once the feature was offered by Windows. These days almost no user except from a few enthusiasts installed the latest version of Windows the moment it was released. It was still easier to implement something using those technologies compared to writing all the various files manually in a consistent way at once. It didn't hurt to be late, but features offered by Delphi were never released on time the moment external dependencies came into play. Delphi never offered a more convenient consistent way of building COM & Co artifacts in a sense of just more easy C or C++, without haven to ship additional BPLs or link proprietary stuff. Delphi .net did away with all that because MS did away with all that when introducing C# .net in V 1.1. better said little later in 2.0. Even if room for improvement was left, those major issued were addressed and finally covered. This game of everlasting catching up returned together with the various SDKs offered for different platforms by the vendors. The idea of giving up on expected quality shipped at the same point in time but on budget never really worked out great for anyone (triangle) and is a luxury today btw. Embarcadero does ship new features and I observe a slowing down almost everywhere, when it comes to tools and technologies. This same problems the vendors of CASE tools have not been in the position to address let IDEs turn out to become one of the most dominant concepts and finally the big winner at the end of the 20th century. Putting a strong focus on just quality would put Delphi immediately into a corner/niche in which Eiffel & Co ended up almost 30 years ago. Today there is not even a niche left because all those who provide technologies designed their own IDE for their niches. - It's hard to change the language in a fully integrated environment when the IDE relies on scanning source code files. I'm aware that Delphi does not scan source code files solely. The big advantage of JARs and .net 'assemblies' hurt C/C++ around 2k. A few years later the hip web programming languages run into pretty much the same problem e.g. PHP4 vs. PHP5 still remaining the best example. When PHP Storm started to address this issue the one idea or the other moved into the mainstream IDEs too for very much the same reason but never made it into Delphi and C++ is a whole different story but today those features are available too. No matter if a community did provide them or the supplier. Since C programmers started to use those languages too the C ish programming style (Schottern slang. ger. ok. Austrian language), writing 50 lines of code and compile them later at one, spread. IDEs adopted into this direction. Think of an article about 'Delphi fighting a battle lost long time ago, in which a former Delphi programmer talked very positive about being in the position to write working code that way without the need to compile, because of being guided by the IDE plus Java technology. Same counts for VS and C#/.net to a certain degree. I call that assisted coding similar to assisted living (residence). Today the last issue, which is no for me personally, is Error Insight. I personally do have nothing but 'Use Editor Font' checked an nothing else enabled in Code Insight. This time I found no reason to turn those features off but I don't have 10.4 installed at the moment. So I cannot comment on how far 'Assisted Programming' is supported today. Error Insight works for me too. - Language: I don't care in general or at all. I'm happy. - Compilers: It makes sense for such a professional tool allowing other tool providers (e.g. threading & Co) to support Delphi Win64 quickly. This has always been missing but since vendors do/did support Delphi 32-bit there must have been a demand. There will be no nice little handy Delphi once again, even if EMB(T) is trying to sell such an illusion. That's not the only reason why tested 'quality' has to be shipped. No one assumes a development system that allows to address such a wide range of applications and platforms the native way to be nice and cuddly but it must work and using it must work smoothly. - In fact we never really went beyond having 4 tabs Standard, Additional, Win32 and System. Ok, dialogs and Win 3.1 for those who have to cope with the ultimate legacy source code. Anything else is usable and well maintained imo. What hurts to a certain degree that from the overall picture/perspective Lazarus/FPC leaves a more complete or compact impression at a first glance. Not talking about what can be done or what the result might be, just from the perspective of how things can be done. In order to build your own controls in sense of widget set today, you needed a continuously improved CDK. For all those who have to maintain millions of lines of code building components for both VCL and FMX is not a big issue very likely. It's very nice to have access to an IDE which MVPs can handle and extend with style(s). This approach sound pretty elite not saying esoteric. Admiring all of you for what you are in the position to do with Delphi, will not help to grow a young generation of programmers within an acceptable amount of time. Kidding. Today people use tools like hardware tools lying around in grand pa's craft cellar or a workshop. I'm wondering in how far it does make sense from the developer's perspective (apart from buying components which introduces a lower but another kind of complexity) to be in the position to create a component (especially) for the GUI but having to consider all available target platforms in order stay happy because of being prepared for whatever target that has to be addressed in the future. Putting silver under the pillow neighter does make you feel save nor does it make you sleep better. On a contrary your will very likely wake up with headache.