David Schwartz

Instead of hijacking this thread with yet another off-topic wall of text about why Embarcadero sucks and Delphi is doomed, maybe you could start your own thread? This was in reponse to the OP who posted a bunch of suggestions for delphi from a Developer's perspective. There have been tons of such posts here and elsewhere over the past decade, some quite eloquent and some more debatable. This discussion forum is dominated by DEVELOPERS, like you and I. We have our perspectives, we love Delphi and we all pretty much would LOVE to see it continue to grow and expand and get better. But after all of the proposals, submissions through official channels, and every conceivable attempt at begging, prodding, and encouraging Embt to do different things, it has become painfully obivous that ... they just are not interested. They don't "suck". They are operating in the best interests of their SHAREHOLDERS. We are DEVELOPERS -- NOT SHAREHOLDERS! SHAREHOLDERS want PROFITS while we DEVELOPERS want MORE FEATURES! Any overlap is mostly coincidence, driven primarily by Microsoft and Apple. Not us Developers. The CUSTOMERS paying the bills want LOW-RISK INVESTMENTS. Everywhere I've worked in the past 10+ years has had one thing in common: they only want me to touch code that HAS TO BE CHANGED. They don't want me to use NEW FEATURES. They don't want REFACTORING. They don't want the code "cleaned-up". A couple changed their policies that require every line that shows up as changed in the change logs must relate back to a specific trouble ticket. "Refactoring" for its own sake was not allowed. They DO want: simple, straightforward changes that use existing coding patterns and language features found in D7-era code (around when the apps were built) so it looks and behaves the same as all the rest of their code. The last place I worked, most of the core code they used in production had not been touched since 2007. I was told on my first day, "DO NOT TOUCH ANY OF THE CODE WITHOUT MY APPROVAL!" I found and documented several bugs, and was told point-blank, "you must be wrong, this code has not changed in over a decade; there are no bugs in it." Except it went from running in Win XP to Win 7 to Win 10, and now it does weird and unexpected stuff sometimes that I captured on camera. They didn't want to hear about it. I asked one Dept head (at a State Agency) why they don't rebuild their code in the latest version of Delphi using more contemporary stuff. His answer: Because their State's CTO basically said, "All new software development will be done in C#/.NET." Period. End of story. Seems their Legislature authorized a 10-year agreeement with Microsoft to provide them with everything they'd need, and that was that. I've heard similar things from multiple places I've worked, both public and private. This is NOT MY OPINION! I personally don't think Embt "sucks". I personally don't think Delphi is "doomed". I think Delphi's evolution is being dictated by two things: (1) SHAREHOLDERS who are only interested in profits; and (2) CUSTOMERS who are interested in REDUCING RISKS IN EXISTING PRODUCTION CODE. I love Delphi. I love the Developer community. And I don't see Embt's focus on Delphi changing any time soon to make it more aligned with that of Developers other than coincidentally. For example, I've seen dozens of proposals for language extensions, many of which would be useful to most Delphi Deverlopers on an almost daily basis. But the only two that were added to D11 ... I've never ever seen discussed. I was honestly totally surprized when inline 'var' declarations appeared in the language. That's a marginally useful feature to me, and not one I would have ever expected to see added. But its introduction broke a bunch of far more useful things in the IDE. They would have been better off not introducing it until everything in the IDE worked properly with it. D11 reportedly hasn't fixed anything that was in D10.4.2. The last place I worked, we were asked after D10.3 came out if there was anything added to the language that might justify the risk of upgrading everything. Inline vars were all there was, and the consensus was that they did not justify anything, especially because they broke a lot of stuff in the IDE. Unfortunately, the company went ahead and paid the maintenance fee anyway. Why? Because the cost of NOT paying was more risky and costly. Yet we're still waiting for MANY VERY USEFUL ADDITIONS to the language! This is how the game has been rigged: customers (companies) will continue to pay their maintenance fees whether they use what's been added or not. And SHAREHOLDERS LOVE THAT! Developers ... not so much.

YES IT DOES! It allocatess space on the stack for a POINTER (assuming it's inside of a method). When you say this: vObj_Instance := TClass_Type.Create(...); it allocates a chunk of memory from the heap, sets vObj_Instance to point to it, then calls the constructor with an implicit pointer argument to that chunk of memory and initializes it based on the code in the chain of constructors that get called. If TClass_Type is defined as a RECORD, then it would allocate enough space on the stack to fit the entire record, and you would not need to allocate space for it from the heap. In C/C++ this would be written as: TClass_Type * vObj_Instance; // allocates space for a typed POINTER // this is the constructor call equivalent to what happens in Delphi vObj_Instance = new TClass_type(...); This is more clear, showing that it's a POINTER type. In Dephi, the call to allocate space from the heap (by 'new' in C++) is always IMPLED.

well, you seem more familiar with what Pascal offered, before Dephi introduced 'class' types. And I don't know what to say about the question regarding EXEs. That's totally unrelated to storage allocation of classes. Or I'm not understanding your question. See if you can snag a copy of Marco's book (ask Google) and work your way through it. That will get you onto very solid ground.

Go to their website, they've got a ton of stuff available. (Unlike EMBT) https://www.tmssoftware.com/site/default.asp You could say they've taken the "javascript as machine code" paradigm to the next level, but they don't really spend much time geeking out on it. Rather, they're busy building stuff with it that's blurring the lines between different OS and CPU boundaries, and making that technology available to Delphi developers. It's sort of like Java's imperative: "build once, run anywhere". Only it's Delphi / ObjectPascal, and the run-time system is built-in to most web browsers today, so you don't need to really even worry about it.

If you have a Delphi license, you can get the latest version of Marco's book from the portal. Maybe it's available elsewhere for free as well. you can also get it from Amazon Kindle here: https://amzn.to/3iuvbTf

What languages are you most familiar with? You seem to have certain ways you're thinking that are not applicable to Delphi, so it would be helpful to know where you're coming from.

What FPiette said above ^^^^^^^^^^^^^ is accurate, if not a bit brief. What you're thinking is how RECORD types work. They act like STRUCTs in C/C++. In the last version of Turbo Pascal, an 'object' type was introduced that was like a class (with both data and method members) that behaved like a record (static memory allocation). When Delphi was introduced, it deprecated 'object' types and added a 'class' type where everything was implicitly derived from a base class called TObject, and variables declared as type 'class' are references (pointers) to dynamic objects on the heap. Unlike regular Pascal pointers that need to be dereferenced with the '^' operator, references to class instances are implicitly dereferenced and allow you to just use the '.' operator to access members. That's one reason why you can see the same code expressed in Delphi and C++ and the C++ code looks horrendously more complicated. (The C++ is closer to what you'd see in Delphi using records or deprecated 'object' types.) There's a free book that Marco published via EMBT that is a great introduction to Delphi. It'll take you step-by-step through all of this stuff. BTW, RECORD types in Delphi have evolved to the point where they're very similar to classes today, but they still retain their static memory aspect when you declare instances of them. Record instances are 'value-based' whereas class instances are 'reference-based'.

It's all find and dandy to come up with all sorts of ideas that we as developers would love to see. But I believe that the reality is that most of the revenues come from corporations who are mostly interested in risk-reduction, not more usable software. I don't believe that EMBT is making most of their revenues from Delphi products because they're being actively used for new product development. Rather, I believe it's coming from corporations that built large apps between 2000 and 2010, and those apps are still producing strong revenues with modest investment in maintenance. These customers have been just running things as-is for the past 10-15 years, and they invest in minor updates to keep them operational. I believe the latest language enhancements are ignored, as are most of the new features. These customers simply keep renewing the maintenance agreements because it's the least-cost thing to do that minimizes their risks in case something unexpected happens. As one of the devs at a place I worked in 2009 liked to say, "We're all here just keeping a comatose patient alive long enough for them to migrate this project over to .NET." During the short time I was there, they missed the first two major milestones for that migration, and the schedule got pushed out by an additional year. The company was REALLY upset when Microsoft announced they were end-of-lifing Windows XP. I mean, these guys were so paranoid of changes to Delphi's math libs that they spent months running a HUGE bunch of regression tests on every new Delphi release looking for deviations in calculations less than 10^-6. Newer releases past D6 failed, and with MS abandoning XP meant it could cost them billions of dollars due to even the tiniest deviations in math calculations. I tried to move them to D2010, but one of their devs built some components that would make most folks here faint due to their total non-conformance with component building guidelines, and they wouldn't build properly under D2010. That's not to say there isn't new development and even innovation going on with Delphi in shops around the world. But it explains why the language itself is at least 10 years behind most contemporary languages; why the most urgent updates to the platform actually track updates that Microsoft, and now Apple, make in their latest hardware and/or software releases; why the run-time technology (like high-DPI stuff) hasn't gotten much attention (because most applications are running on machines barely capable of displaying full HD resolution); and why nothing reflects much concern for anything other than Microsoft, Windows, and making the run-time libs more similar to C# libraries than anything else (IMHO). ********************** If you want to see REAL INNOVATION in this space, take a look at what TMS Software is doing. They've created a more intentional and cohesive extension of the Delphi platform in the past 18 months than EMBT has done since they bought the company from CodeGear. I can't say for sure, but I suspect a larger percentage of their revenues come from developers who have a larger say in their future wants, needs, and desires than your average IT Manager or CIO. They're actually intersted in things that are not tied to Microsoft or Apple and extend into a more homogeneous cross-platform ecosystem that has web development in the center of everything. They are solving difficult multi-platform problems that EMBT should have been working on for 5+ years now if they really cared. And they are not waiting for EMBT to address any of the shortcomings they may encounter. One of their key players, Dr. Holger Flick, has written and published three (3) new books in the past 18 months, with more coming! With TMS tools, you don't even need Delphi to build Delphi apps that run in more platforms than EMBT supports TODAY! (See the screen-shot below) You can build them in Visual Studio Code, and using Lazarus you can even build executables that run natively on Linux machines without having to spend thousands of dollars on an "Enterprise Edition" Delphi license. We don't need more threads trying to lay out a direction that EMBT can take to make Delphi nicer for Developers, because Developers are clearly not EMBT's target market. (I don't know about you, but in the past 15 years, I've been the only person every place I've worked who had my own personal Delphi license to ensure I could keep up with new developments. That's because the production code at most places was a few releases behind the latest Delphi release.) Get invovled with TMS products and see if there's something there worth focusing on. Not their older VCL, FMX, and Intraweb (gawd, is that still around?) libs, but the newer WebCore, FNC, and Business Suite stuff. Their next release of WebCore will let you create web apps that run natively in more platforms than Delphi supports, including Raspberry Pi -- without requiring you to have access to a compiler that generates ARM code. And you won't need to have your dev machine tethered to another dev environment to do cross-compiles. (I know this is going to raise some hackles, so ... I say it's "native" because there's a wrapper that runs as a native app and it allows the code encapsulated inside of it to run within a web browser. There's no hardware that runs javascript in the same way there's nothing that runs java bytecode.) The photo below is a snapshot from a video they posted recently illustrating support for the Raspberry Pi. that shows the platforms WebCore will support in its next release (which will probably be out before EMBT releases their first "bug-fix" update for D11) using either Delphi or VSC as your dev platform. Their strategy does NOT depend on what Microsoft or Apple may or may not do, or what the next release of .NET or iOS might provide. WebCore targets javascript running in the web browser, which is becoming more universal than Windows. I invite all Delphi developers to stop complaining about what EMBT is NOT doing and start cheering on and supporting these guys who are actually INNOVATING around the Delphi language and EXPANDING the Dephi ecosystem -- RAPIDLY! (Buffalo Springfield's song, "For What It's Worth" is echoing in my head...)

That may be true. I saw it discussed elsewhere and that's why I was looking for that article, because I didn't think it used them. Haven't found it yet, tho.

Back when Delphi was owned by Borland, they had a fairly generous policy towards handing out free copies of their software products. Their actual "Cost of Goods" was tangible since back then sofware came on disks and there were always books included in the boxes. (Delphi itself was given out free to everybody who attended the launch event in 1995. I was there! And lots of free stuff was handed out at all sorts of conferences throughout the 90's. But those things have faded out, along with User Groups and similar in-person events. I did do a local in-person event as an MVP a few years ago, and they refused to give me a free license to raffle off. But they did send a bunch of pens and note-pads -- at far greater actual expense than a license code sent via email.) Today you have to pay to get a DVD if you want a physical copy on disk. The COGs is ZERO. Yet Embt fails to see the value in giving away licenses for any number of valid reasons that used to be commonplace. Even MVPs only get a license that's valid for 365 days. Even though the COGs for Delphi are ZERO, they build-in a 4% automatic increase in the maintenance agreement every year. When was the last time anybody here got even close to a 4% raise from their current employer? I don't think I've EVER gotten a raise over 2.5% without changing jobs. Honestly, I may be done upgrading Delphi. I let my maintenance agreement lapse just before D11 was released and I'm not missing it a bit. The whole world is moving towards web-based products and the only thing in D11 of any consequence is support for Microsoft's new Windows update -- because I suspect most of the revenues for Delphi come from thousands of corporations who are beholden to Microsoft and will all be upgrading (whether they like it or not) over the next 6 months or so. This creates a lot of maintenance work, which seems to be the only thing anybody hires Delphi people for today. Nobody is building web stuff using Delphi. Most companies are moving towards a "mobile-first" approach to apps, and even that is being dominated by Microsoft in many shops. Which means C# and .NET. Hobbiests are not buying Delphi for its cross-platform benefits because all the tools and libraries needed have FOSS licenses. But TMS has this thing called WebCore and you can build web apps in Delphi with it. In fact, you can even use Visual Studio Code, which is free, instead of the Dephi IDE. They just made all of their FNC components so you can add them to VSC, quadrupling the number of components available for WebCore apps. And they're preparing an update to their "wrapper" technology (Miletus) that's like Electron and lets you take a web app and turn it into a native app. The next version will support more platforms than Delphi, including Raspberry Pi's. I have an ALL-ACCESS license from TMS and the annual cost to renew it is less than half of my Delphi Enterprise license. It doesn't automatically increase by 4% annually, and it buys me a collection of tools that offer far more flexibility and relevance in today's market. They're also not afraid to add valueable things to the language that WebCore supports (Object Pascal) that people have been asking for in Delphi for ages. They're constantly adding more and more cool things to their platform; it's enough to make your head spin. Meanwhile, this latest Delphi release had nothing new that I need in it. It doesn't even fix the Refactoring bugs introduced in the last couple of 10.4 releases. They still charged 4% more for it again; but to me, it failed to deliver even 4% more value over 10.4.2. If I look at what has happened with Delphi over the past 12 months, and at what WebCore has done, there's no comparison. WebCore is moving faster in directions that the market is embracing, while Delphi is simply providing support for the latest version of Windows, hoping to justify its existence for Corporate IT Depts who need to decide whether to write a check to keep the maintenance releases coming or not while all of their new development is being done with other tools. And here we are debating on whether this huge billion-dollar corporation can afford to give a comp license (that doesn't cost them a penny) to a guy who has contributed more value to the Delphi community than most of the new features and bugs they ship with every update they put out. Same debate, different year. I think the problem is that most Corporations are very slow to move new Delphi releases into production, so they don't miss delays in updates for big component libs and things like what Andreus does because they do make it out sooner or later anyway. I think Embt is really only interested in Corporations because they just keep renewing their licenses and don't do much otherwise. They don't care about language features, only whether it supports the latest Microsoft Windows needs.

I don't think it used include files. It's just something I remember seeing and wanted to review, but I can't remember where I saw it. Maybe in a book or an article somewhere.

You're trying to use a default mechanism that was defined for the convenience of the IDE and basic run-time system. If it doesn't work for some of your units or objects, you'd probably want to somehow "register" your objects that have an ordering dependency with something of your own creation (a dictionary or directory of some kind), then initialize them in whatever order you need. Similar to what you'd get using a DI container.

When Delphi first came out, seeing how this worked was one of those O-M-G! moments! If you've never programmed the old Windows event loops using Microsoft's crappy old "object framework" based on C++ but not really using objects, it's really hard to appreciate what the inventors did that actually hid all of that garbage. I don't think any of us really learned any of that "complicated backstage" because ... honestly, who cares? What it did was SIMPLIFY THE HELL out of creating forms in MS Windows apps. Not even VB was that elegant at first, because you had to write VB components in C++ due to the Windows part of that "complicated backstage". Delphi let you write components in ... Delphi! In large part because a TComponent had certain magical properties that let you drop it on a form and refer to everything in it as if it was part of the form. It was really ingenious, and so intuitive that nobody really gave it much thought. So coming at it the way you are, from the "run-time first", it's not surprising that you're confused. If you're going to do it that way, then study how to write components. That may confuse you even more at first, but at least it will get you going down the right road. That said, your naiveté might lead you to figure out something that the rest of us are blind to because we've been working with this for so long. The biggest annoyance I have is when I want to derive something from a common component, like a TLabel and make a TmyLabel with additional fields and methods. But you can't then inject it into the form easily because the IDE needs all components to be registered and installed, not just declared. I think I've seen some ways of doing it, but they've never stuck in my memory. So while this mechanism was almost miraculous when it was first introduced, it does have its limitations.

This is actually quite informative and very inspiring! But I don't think this is the kind of thing the OP meant when he said, "which can download all data of competitors (items description, prices etc.)". It read as if he wants to populate his own sites from data extracted from his competitors' sites. I've written lots of things that extract data from HTML pages over the years, but some of the mechanisms being used to prevent that lately make it more of a hassle than fun. I'd not heard of these tools, so it's good to learn of them. Thanks!

That's pretty interesting... ScrapeStack lets you unwind the javascript encoding, but they say it returns a raw HTML page, which means it still has to be parsed. So CSS can still trip you up unless the headless browser used for unwinding javascript handles that for you as well. (They don't say, but ... it probably does.) So even if there's no javascript that needs to be processed, you might want to select that option anyway just to get the CSS processed. I played with SerpStack a bit, but then I found ScaleSerp and I like it better. Both return a JSON data packet. My only beef with it is that it has several types of queries, and while they have very similar results, it's as if different people wrote each one, because the field names used in the JSON data for the same data items often aren't the same. So the code that processes each of the different types of queries needs to be different. Luckily I'm only interested in a half-dozen of the fields returned in each of the different JSON packets. But it's just odd to see. I'm mentioning this because ... this represents the "state of the art" at this point in time. We're early-on in this technology curve. (I've been playing with this code for a couple of months, and the data results have changed several times because Google changes their page layouts and encoding mechanisms a lot. I've even found some bugs in the JSON data. It's worrysome to think of publishing a product that relies on something like this where you KNOW that what you're working with is a moving target.)

Hello guy, before you do this you should know that in most cases, what you're proposing to do is going to violate copyright laws in most countries. Are you sure you want to take that risk? To answer your question, "screen-scraping" used to be a means by which applications written to run on PCs were made to interact with virtual terminals attached to what were usually bigger time-sharing computers (mainframs and mini-computers). There would be a form on a screen and the data fields were in certain positions that were always fixed on the screen. (This was a time when terminals were like TVs that showed text as green or white on a black background. They had 80 columns and around 24 lines.) The software would "scrape" (basically, it meant "copy") the data out of those fixed locations and put it into its own variables. (Crawling is not really related to what you're asking.) For web sites, this approach (page scraping) isn't very practical for a number of reasons, unless the material you're trying to scrape is from a report that uses fixed-width typeface on a simulated paper sheet. Rather, It's much easier to just take the raw page data, which is in HTML, and "parse" it to find the fields you want. But this is not nearly as simple as it sounds, especially if CSS is involved. Parsing is a rather complex topic and is usually taught as part of a computer science course on compiler construction. There are two parts to building a compiler: The first is parsing the input file; the second is emitting some other code based on the input stream, usually a bunch of machine instructions that get "fixed-up" by another program called a "linker". Most compilers are called "two-pass" compilers. (Some do more than two passes.) In the first pass, the parser builds what's called a "parse tree" that the second pass crawls down and processes, either depth-first or breadth-first. As it crawls that tree, it emits code. If there's any kind of optimization going on, the tree can be adjusted first to eliminte unused code and combine parts of the tree that are sematic duplicates. Every programming language, and most things even down to simple math equations, need to be parsed in some way. In this case, what you're emitting is not machine instructions but the content you find in and around the HTML tags. Also, be aware that CSS is often used to position content in different places on the page and it does not have to appear in the same order as the text around it. That is, the page could lay down a bunch of boxes or tables, then the headers, then the footers, then the data -- either in columns or rows. And there can be text data with CSS tags that say to hide it, or display it in the same color as the background color so it's invisible, and that can be done to scatter garbage all over the place that your parser will think is legitimate content, but a users looking at it in their web browser won't see any of it. Parsing the HTML (which is a linear encoding) won't give you any clue that the content is being generated in some apparently random pattern. So what your parser puts out looks could look like someone sucked up the words in a chapter of a book and just randomly spat them out across the pages. You'll have to sit there and study it and look closely at the CSS and figure out how to unravel it all. Then the next page you get could use a different ordering and you'll be back to square one. The thing is, with the increase in the use of client-side javascript and CSS to encode content and render it in a non-linear order, it's getting harder and harder to algorithmically extract content from a web page. It should also be fairly simple to render the input data on the virtual page that's displayed on the screen, which is what the web browser seems to be showing you. But my experience is that's not necessarily the case. You could always take the bitmap image from the browser's canvas and process it with OCR and see if that's simpler than parsing the input stream. It really just depends on how much effort the vendor wants to put into making it difficult to extract their content. For example, run a simple google search query and then look at the page source. Copy it all and paste it into a text editor and turn on word-wrapping. Good luck making sense of it! Repeat this by running the SAME QUERY a few times, then do a diff on each of the resulting files (if it's not obvious just looking at them) and you'll see what you're dealing with. Pick some phrases in the original page and search for them in the text editor. Some you'll find, and most you won't. Yes, it's fully HTML-compliant code. Yes it can be parsed with any HTML parser. But I guarantee you that a lot of the text you want is embedded inside of encoded javascript methods, and no two take the same approach. To make matters worse, they change the names of the javascript functions and parameter names from one query to the next, so you can't even build a table of common functions to look for. So you'll need a javascript parser that can execute enough of it to extract the content, but not go any further. A lot of it is structured like a macro language, and it uses multiple levels of "encoding" or "embedding". When you try unwinding it, you don't know how deep it goes, and if you're not fully executing the code at the same time as parsing it, you can end up "over-zooming" and miss what you're looking for. They can also bury little land-mines in the code and if you try decoding something it can get scrambled if you don't have something else loaded in the run-time environment that's totally unrelated. Or it could use a function loaded way earlier that doesn't look related that unscrambles some important bit of text that will stop the parser or run-time interpreter if it's not correct, and what you'll end up with is just a bunch of gibberish. It used to be fairly easy to parse Google search result pages (SERPs), up until 2-3 years ago when they started making them quite hard. Some other sites are starting to do this now, like Amazon, eBay, and others. Why? Because it's the only way to deter people from stealing their copyrighted content! They know that YOU DON'T GIVE A RIP about THEIR COPYRIGHTS. And it's a lot easier now to use multiple layers of javascript encoding to hide content than anything else. I've also seen CSS used to embed content. CSS is NOT HTML. You can parse HTML and end up with just a bunch of CSS tags and little if any content. Good luck with that as well. So now you need a CSS parser! Is your head spinning yet? Ask yourself how much you think the client is willing to pay you to figure all of that out, and realize that it's all being constantly changed by the vendor, so it's a moving target that will work one day and not the next. Honestly, if you're going to risk stealing copyrighted content from other sites, hire people in China or India and pay them per-piece to copy stuff by hand from the other systems into yours. It will be a lot faster than trying to write and maintain code that parses all of this stuff. (I found there are a few companies that do this for Google SERPs and they charge a bit to get the data you want. Maybe some exist for the sites you're interested in robbing of their intellectual property?) Even if it's not that complex to parse their data, pray that you don't get caught. TIP: the fact that you asked your question the way you did tells me you're looking at a minimum of 6-9 months to write the software you think you need, if you can even get it working steadily, because you're going to have to learn a lot about parsing first. I suggest you hire someone with a computer science degree who already knows this stuff. TIP: writing a parser can look seductively simple at first. It's not. And the obvious ways of digging into it without understanding anything about parsing will usually lead you into a dead-end alley. HTML is fairly easy to parse, and there are several components you can get that do an excellent job of it. But again, CSS and javascript are not HTML, and they'll stop you dead in your tracks if they're used to obfuscate content in any way, or even in the case of CSS to do page layout in a non-linear fashion.

It seems like I've been getting an unusually large amount of Win10 updates forced upon me by Microsoft lately. I checked a setting to reduce the number of updates to as far out as I could, but it just kept loading stuff down. I finally dug around and I think I figured out how to shut off the updater entirely. Of course, about two hours later I got another update.... Anyway, since one of those things came down last week, my Delphi 10.4.2 IDE has been unstable as hell. It freezes up when I open the Inspector and click on certain things. I can't close the app, and have to just force-quit the whole damn IDE and restart it. Now I've got weird stuff happening, like when I right-click on things with a popup menu attached, the sender.popupcomponent is not pointing at the thing that was clicked. I can't even find the object that caused the click. This is going through some Windows Messaging stuff. I can trace through the popup code in VCL.Controls. The sender is the TPopupMenu, but when it comes out in my app, it's the TMenuItem that was clicked, not the TPopupMenu. Classname is 'TMenuItem', although I can cast it to TPopupMenu and there's something in PopupComponent, but it's garbage. I'm just wondering if anybody else has noticed any weirdness with 10.4.2 in the IDE, particularly when debugging, in past couple of weeks, possibly due to Win 10 updates?

I run Dephi on Win10 installed in a VirtualBox VM that I rarely use to access the internet. It mainly happens when I click something in Dephi's help and it goes out to the Wiki -- which half the time is a broken link. And there's very little that I install in it beyond a few common tools I use regularly and Delphi itself. Windows represents 95% of the stuff that gets downloaded directly into the VM, and I really hate the fact that it seem to be constantly downloading updates and running the background builds on things. I run AV checks from time to time and nothing turns up. Only once did I have a problem. I shut the VM down, deleted it, and pulled the last backup copy off of the backup drive and went back to work. No more problem.

The above is fine except: (1) people who are not using the app will get the message; (2) people who are not affected by rebooting a server they're not using will get the message. If you want to notify people using your app that the server it's connected to (that may not have any other connections to it) is going to be restarted, then have a mechanism that lets you notify the users of that app based on something as simple as what's shown above, reading a file and displaying it. I've seen this approach in several large apps over time, and nobody complains about performance. Indeed, calling FileExists every 60 seconds is hardly anything anybody would notice.

You obiously haven't learned yet that this is pretty routine if you're in a super-hurry to install an update as soon as it's released. I used to enjoy playing with beta code. But these days, I usually won't bother to install a new update until their first patch is released. Just too many problems to be in such a hurry.

You guys might want to watch the webinar replay.... They mentioned a surprising number of little tidbits like these, most of which I didn't bother to make a mental note of. What I was left with was they were primarily focused on the high-DPI stuff; the ARM-64 code generation; the ability to split out a separate window that can be toggled with the main window to swap the code editor and form deisgner; and a bunch of other stuff that's really of no interest to me. Oh ... I almost forgot ... they finally updated the RichEdit VCL control to use the features Microsoft introduced about 14 years ago. So now you don't have to use whatever 3rd-party lib you bought years ago to get past basic Win XP features. (TRichView anybody?) Note: it ONLY affects VCL (b/c it's based on a Windows control). And there was some talk about the new web browser control. (Also Microsoft specific.) I really hate the fact that they have their licensing set up such that if you find insufficient value to "reward" them with a license upgrade, they double the fee then double it again. There's not enough here to justify the cost of this upgrade to me. I get 10x the value from my TMS All-Access pass for 1/3 the renewal price. And with WebCore, you don't even need to use the Delphi IDE any more! HA! VSC Code does all you need. (Oh, there's a VSC Code plugin so you can use it to edit your Delphi code. Can't compile it. And the editor they spent a bunch of money to acquire still isn't integrated into the IDE.) What I want to know is ... what is their Marketing Dept doing to grow and expand the market for all of this useless technology they keep creating while ignoring stuff existing developers want? TMS is going gangbusters! Delphi's Marketing team seems to be asleep at the wheel. There are have only been two jobs on Dice this past couple of weeks for Delphi devs and they were both back on the East Coast of USA. The world is moving towards the web and distributed computing via SaaS resources, and Delphi seems to be just standing around getting fitted with another batch of designer clothes to look better to a shrinking audience. Delphi has turned into the Kardashians of the software world -- it's all about the looks.

I intepreted that to me the "font size" of the text editor, and the slider at the bottom of the editor window lets you do that. It's not a 3rd-party plugin. I am not aware of anything that lets you adjust the "GUI font size (menus etc.)" including a slider. Maybe THAT WAS a 3rd-party plugin you saw.

The Registry is a persistent store that is available for any Windows app to use. It replaced the uncontrolled and often abused use of INI files. Maybe your apps don't use either one, which is fine, but it's fairly common to use one or the other to do things like saving the states of different forms and where the users are in some work process. It's simple data and not usually worth putting into a DB if you're not already using a DB. INI files are just files with a .INI extension, so they're easy to capture along with other files. But Registry entries are another thing entirely. They can be simple or complicated. (The last place I worked, we were forbidden from using the Registry for security reasons, because it had been so abused by previous devs saving too much PII in it that posed potential HIPAA violations. The Registry tends to be a write-mostly memory bank and when you delete apps, the registry is often left un-touched.) The problems arise when you use it to save login credentials, access criteria, license keys, names, addresses, phone numbers, and things that you don't generally want anybody to see, but may be essential to the operation of your app. The average user is clueless where stuff like this might be saved, or if it even exists, so it's a safe place to hide stuff from everybody but developers. We're "smart rats" and know where to look! Apple has something similar to the Windows Registry, but it's not as obvious. Kind as they are about most things, When you upgrade MacOS, it conveniently "loses" all of the registration keys for Apple's software. I suspect that's intentional on their part. But as a developer, it's smart to stash this stuff away periodically if it contains any hard-to-get-at data. A lot of user-customization data is saved in the Registry -- eg., it's where Delphi saves all of the settings under Tools -> Options. There's a LOT of stuff there! That's why, when you update to a new version of Delphi, it's so damned difficult to restore your menus and toolbar to the previous settings! They don't always map nicely from one version to the next. (Personally, I would NEVER subject my customers / users to this level of abuse when updating my software! I want it to be as painless and forgiving as possible.) But the old saw, "out of sight, out of mind" applies to the Registry if you use it for saving anything. Most folks don't think of it when backing stuff up.

You have two main channels you're going to focus on using: 1) Your app 2) The OS If you know everybody is using your app, and that's who is going to be affected, then have the app poll for messages periodically and alert them when one shows up. If it's anybody using the server, then use the OS and broadast to everybody logged-in.

Yeah, that's what I meant. 🙂