David Schwartz

I started my professional career working with embedded systems for nearly a decade, so I guess that's why hardware like this catches my eye. This isn't particularly useful for ordinary office tasks or testing or anything like that. But it would be great for a standalone kiosk, or some kind of dedicated application. For years you needed to use an embedded OS and special tools to build stuff that ran on specially-designed hardware. Today you can get a Raspberry Pi for under $50, sure, but you can't build stuff that runs on it with all versions of Delphi. Lazarus and FreePascal perhaps, but those are a lot more limited than a standard Delphi release. This little box includes Win 10, and for the price, the hardware is practically free -- most of the cost is likely going to Microsoft for the Windows license. While that does not excite me, the fact that it's possible to use the same toolchain to build an app for a simple embedded application that runs on an otherwise standard Win 10 platform is far more inviting than the prospect of having to use a whole separate toolchain instead. I can't tell you how many projects I worked on where Management would order special hardware and compilers for builds, but then try to "save money" by not buying the debugger, so we had to use link maps and assembly output from the compiler for debugging off-line. I've always had this vision of little functional building blocks, like "smart" Lego blocks, that perform specific functions and can be plugged into a network and used to solve specific problems. A great example of this is being able to plug your phone into your car and access stuff on it like media, email, messaging, and calls, as if it's built-in. Most vehicles come with something provided by the auto company that built the car, and you're stuck with whatever they want to provide. It's a huge expensive effort for them to add, and it ends up being a political and economic decision for them because they want to retain control. I have a 2017 Toyota Prius Prime and one of the biggest complaints on a forum where Prime (and Prius) owners hang out is Toyota's adamant refusal to add this ability to their vehicles. They offer a horrid UI design and the same crappy mapping that auto manufacturers have used for 15 years. The stuff on our phones seems like it's light-years ahead. When I bought the car, the sales guys bragged "It has Google Maps now!" I don't know what part of their mapping is from Google, but the overall experience is the same crappy mapping I had in my 2012 Prius and in a Garmin GPS from 2005. I hear that Toyota has finally broken down and will be adding support for Apple's car interface to a couple of (non-Prius) models for 2021, but everybody else is out-of-luck. Why is this such a problem for them? Because 100% of their computing platform is dependent on a proprietary hardware design, proprietary embedded OS, proprietary interfaces, and a desire to keep total control of the user's experience. Why? Risk. It's pretty absurd when my iPad Mini has more computing power than the stupid crap they include at the factory and want you to believe is "the best available technology". Yeah, right. They just don't want to get sued by some problem your phone might have caused while you were driving. Look how long it took car manufacturers just to offer a common 1/8" stereo AUX-IN jack to allow people to plug-in their iPods! As far as risks go, I can get why a brand new 787 jet employs CPUs on it that are equivalent to what Apple used in 1990 -- they want stuff that is absolutely rock-solid and has millions of hours of flight time and testing time on it. But I don't need that level of reliability simply to select the tunes I want to listen to while I'm driving, or to display maps. Alexa is another example of an embedded system, but it's an approach that scares me in terms of its ability to expose everybody to unethical and even illegal purposes. But that's a discussion for another day. 🙂 That's how I think of embedded systems that affect consumers -- standalone functional building blocks that use standardized software and interfaces to allow developers like us to offer customized features they just can't get any other way. I started my career in 1979, and this kind of utilitarian application of small standalone computers seemed "just around the corner" in the mid-80's. Here it is 2020 and in spite of a huge proliferation of fully programmable portable computers (a la mobile devices) and almost unlimited access to connectivity to everything, we don't seem any closer to this than we were in the 80's.

Anybody have any idea what would cause all of the .res files to get deleted from the ...\lib\win32\debug folder? (Actually, there's one left: FireDAC.VCLUI.PanelTreeButton.res) There are 49 in the \release folder.

so perhaps the release folder got removed from the search path, then? I'll check that. Thanks. BTW, I don't usually use Debug DCUs although I seem to get them more often than I want. It's super annoying hitting F7 to step into a function call and end up in a long chain of RTL code that is totally irrelevant.

If they don't get installed there, where is the compiler expecting them to be?

wow, that's weird. Last Friday I started getting compile errors saying it could not find controls.res, tbutton.res, and another. It was late in the day and I forgot about it. Today I tried to build a different project and got the same errors. I looked in the folder and nothing was there. The folder is in the search path, tho. I copied them from the release folder and they disappeared about 5 minutes later.

looks like there might be some security app the IT guys installed that thinks they're a threat

It says it comes with Win 10 installed, but you can also install Linux. I didn't want to start a debate about running Delphi on this. I wouldn't want to. I was thinking of it mainly for use with embedded or dedicated Delphi apps.

[this seems to have gotten lost at the end of my other message] I set up a TWebBrowser in one tab on a form and the image processing stuff in another tab. I can drag-n-drop the image link from Chrome to an area at the top of the form. It switches to the 2nd tab and I click a Process button. That causes the browser to navigate to the image, which it loads into the browser window. Perfect. Now I just need to grab it. But ... while I'm getting the height and width of the image from the target image, I'm not getting the image to show up most of the time. Sometimes, but mostly not. I'm finding the image files on the page using IHTMLElement2.getelementsByTagName('img') and grabbing the first one (since I know that's all there is on the web page). img := getFirstImage; Image1_frame.Height := img.height+2; Image1_frame.Width := img.width+2; rnd := img as IHTMLElementRender ; rnd.DrawToDC(Image1.Canvas.Handle); Image1 is aligned to Client on a panel Image1_frame. So I set the frame's H & W -- they get set ok. But the image is usually not visible. It's just white. I see that DrawToDC is deprecated, but I haven't found what to replace it with. What am I missing here?

We have a ticketing system where we get tickets for work, and sometimes clients send image files to us for different purposes. They get attached to a ticket and the ticket is forwarded to us. They're supposedly PNG files. Currently, I have to right-click on the image link and then Save As... and save it to a specific folder with a slight change to the name. Then I open an imaging tool we have and I have to click the Open button, find the file, select it, then click some buttons in the program, then click a Save button, saving it with a slightly different name, then move on. I'm trying to simplify an otherwise tedious manual process. I want an app that lets me click on the image file URL, drag it to a form, then DL the image, do all of the stuff, and save it. Easy peasy, right? I've got the drag&drop and creating the URL and target filename. When I try to load the file via Indy's http.Get method, it loads something, but I finally figured out that it's not an image. It's a frigging HTML file! When I saved it to disk and looked at it in the browser, it's a stinking LOGIN page. I'm like WTF? The initial response from the http.Get is a 302 redirect, which isn't surprising. There's a HandleRedirects checkbox on TidHTTP and I checked it. That lets the http.Get succeed. But then ... how in the heck do I get it to work just like a right-click -> Save As ... ? MS := TMemoryStream.Create; image := TWICImage.Create; try idHttp1.Request.Accept := 'image/png, image/gif, image/jpg, image/jpeg, image/tif, image/tiff, image/bmp, image/x-bmp;q=0.9,*/*;q=0.8'; idHttp1.Get(URL, MS); hdr := IdHTTP1.Response.ContentType; // this is: text MS.Position := 0; memo2.Lines.LoadFromStream(ms); // saving to a memo to see what it is, since it seems to be text // turns out it's an html login page!

ok, I set up a TWebBrowser in one tab and the image processing stuff in another tab. I open the ticket and can drag-n-drop the image link to an area at the top. It switches to the 2nd tab and I click a Process button. That causes the browser to navigate to the image, which it loads into the browser window. Perfect. Now I just need to grab it. But ... while I'm getting the height and width of the image, I'm not getting the image to show up most of the time. Sometimes, but mostly not. I'm finding the image files on the page using IHTMLElement2.getelementsByTagName('img') and returning the first one (since that's all there is on the page). img := getFirstImage; Image1_frame.Height := img.height+2; Image1_frame.Width := img.width+2; rnd := img as IHTMLElementRender ; rnd.DrawToDC(Image1.Canvas.Handle); Image1 is aligned to Client on a panel Image1_frame. So I set the frame's H & W -- they get set ok. But the image is usually not visible. I see that DrawToDC is deprecated, but I haven't found what to replace it with. What am I missing here?

hmmmm ... now that's an interesting approach ... I'll still need a way to select each individual DL link because the way we do things in this case uses the same ticket to collect these requests up for a whole month, as there can be a dozen requests or more. We only want to deal with the latest ones, and there might be one, two, or even three at once.

Yeah, I woke up this morning thinking it's probably looking for a login cookie. I wonder if there's some way to have the http component look up the cookie in the other browser's cache? I'm clicking and dragging from browser window A to the app, and I guess the http component looks like an unrelated browser window B. I don't really want to force the user into a second login. That said, I could add Name + Pwd fields to this little app and save them, but that's getting into a very muddy area here.... There are a few Authorization events in IdHttp component: * OnAuthorization * OnProxyAuthorization * OnSelectAuthorization * OnSelectProxyAuthorization I guess Right-Click --> Save As ... runs in the security context of browser window A, but a drag&drop runs in the context of browser window B. I wonder if I can set up a proxy of some kind? They really should be the same context.

I'm working with TMS Web Core, which pretty much mirrors the VCL. I want to be able to switch between a "configuration" mode and a "run" mode. So say you click an Admin button somewhere and it flips a switch so that whenever you click on something it sends the object's instance pointer to a single handler rather than activating the normal mouse events. Then depending on the object selected, a property form will popup that lets you change certain properties. Some of the properties represent meta-data, and some are actual content. For example, if you click on a box that represents a video, then it will ask for a link to a video and a thumbnail. If you click on a text box, then it will ask you for the text you want to display. I don't need a full designer, as I don't want to move anything around. I just want to suppress the normal mouse events and route everything through a single handler. If this was just a normal Delphi VCL app, what's the best way to handle this at run-time? (No IDE is running, just the EXE.)

Hmmm, gotta see how that's done in Web Core.

You missed the part where I said this HTML page is a LOGIN page. The only image on it is the company's logo. That's not what I'm looking for. The URL is pointing to an IMAGE FILE. Not a login page. The MIME type is "image/png" not "text". And a half-dozen questions on Stack Overflow where people asked how to DL specific files, this is the approach that was recommended. Not one of them even hinted that a TWebBrowser is needed. Right-click --> Save As ... actually saves a PNG file. Not an HTML page. Always. The image is in a download folder. Not on a LOGIN page.

I've never had a problem installing a bunch of component libs and then restarting Delphi afterwards. I don't understand why so many libs that GetIt installs require Delphi to be restarted after each one. And after it restarts, it doesn't even have the courtesy of leaving you back where you were when it initiated the restart.

this makes sense if I'm going to USE what I just installed. But if I'm in the process of installing several components, then there's no need to restart because none of them depend or refer on the others. They're all self-contained. It works fine to restart after you've installed the whole batch. At least, I've never had a problem except for some unusually complex installs.

What's your take on whether a FE and BE should be accessible from the same page / form or completely separately? I've seen desktop apps where the Admin / setup stuff is a totally separate app, and apps where there's a Setup / Config / Options link in a menu. Wordpress is infamous for their "Meta" section with a "Login" link to get to the Admin dashboard. You can't separate them even if you wanted to. SaaS solutions often take you to an Admin area that's separate from where your Users will go, and that generates the User's view elsewhere (frequently a subdomain). I've never given much thought to this. But with things like TMS WebCore, IntraWeb, UniGui, and others for building web apps, now I'm curious.

I'm working with some code that was written many years ago, and it uses threading to circumvent delays that tended to occur back when computers were slower and it took a while for the UI to update. For the most part, these apps were headless -- just stuff that ran on a server and spat out log files to document their travails. The thing is, the log files are too sparse; there's not enough info in them to support any sort of auditing. So now we're finding that the program has been failing to update things in the DB and side storage for years and nobody knew. I'm trying to add code to capture more details to the log, but I'm getting random AVs that I suspect are due to the threading not properly synchronizing with the main form. Access violation at address 0040DD41 in module 'DocLink.exe'. Read of address 00000001 The code uses this to send data from the thread to the main form: procedure TSequence.StatusOut(const stat: string); begin if (MainWinHandle <> 0) then Windows.SendMessage(MainWinHandle, WM_STATUSOUT, LongInt(PChar(stat)), 0) end; //---------------------------------------------- // this seems to be the other side in the main form: procedure WMStatusOut(var Message: TMessage); message WM_STATUSOUT; . . . procedure StatusOut(const stat: string); begin LogWrite(stat, true, true); FrmMain.memStatus.Lines.Add(stat); Application.ProcessMessages; end; procedure TfrmMain.WMStatusOut(var Message: TMessage); begin StatusOut(PChar(Message.WParam)); // local StatusOut procedure inherited; end; The main form stuffs it into a TMemo (memStatus) as well as sending it to a logger. I've done some research and it seems that SendMessage should be sufficient. It's ok for low volumes of traffic, but as I send more data, the threads start throwing these AVs. Personally, I don't see any need for threading today, but it is what it is, and I'm not about to redo everything to remove the threading. Any suggestion on how to deal with this? BTW, I'm only guessing that this is the problem. We've got a version of this code that has been running for 2-1/2 years with none of these errors showing up. It's only now as I'm trying to capture more details in the log file that I'm getting these errors.

nearly every question posted here can be answered with "it depends" and stop right there.

I have mixed feelings about this stuff. One big one is that Borland / Inprise really dropped the ball back in the D6/D7 years when they thought it was a Good Idea to hitch their wagon to .NET and everything Microsoft. They made some improvements in the language that left a lot of customers in the dust holding a bag of rocks. Here we are today and they're complaining that these same users STILL don't think it's worthwhile to invest in moving past D6/D7. Sheesh. Developers cost 2x-3x more today than they did back then, and if it didn't make financial sense to upgrade back then, then surely it makes worse sense today. Embt is not making any more friends complaining about the resources these legacy clients are costing them. The problem isn't the compiler -- it's the 3rd-party components like Dream Components that died on the vine and couldn't easily move forward. If they want to fix the problem, Embt should consider buying the rights to these old component libs and investing their own resources in making them work on the latest versions of Delphi. Add them to GetIt and give people a legitimate upgrade path. Whoa! What a novel idea! Still, a lot of folks still won't consider upgrading because it's harder than ever to find developers with solid Delphi skills today. (I think it's easier to find COBOL programmers today than Delphi folks!) Another option is to have a separate maintenance program for legacy products. I have not found a single job in the past decade doing NEW Delphi work -- it's all supporting LEGACY apps that were written in the D4-D7 years. Maybe they're using newer versions of the compiler, but it seems silly to me that the company is COMPLAINING about the fact that all of these old legacy clients are refusing to pay their ridiculous maintenance fees to stay exactly where they are. It's nice that Embt wants people to move forward, but until more jobs start showing up for NEW DELPHI PROJECTS, they're doing little more than Sisyphus pushing a rock up a hill while complaining about the effort involved. They (previous Mgt) created this problem but they don't seem to want to fix it. The world is moving to Open Source Software. Delphi is one if the few remaining products that's not just NOT OSS, but VERY EXPENSIVE for commercial use. Microsoft subsidizes the crap out of their dev tools, as do others like IBM and Oracle. I think the best thing for Delphi would be for Embt to push to get Delphi acquired by a company that can afford to move it in the direction of OSS by subsidizing it from other product revenues. Instead, they keep raising the costs to customers who are mostly using it to MAINTAIN OLD CODE. I'm working on my 4th or 5th gig since 2009 that's maintaining code written prior to D2007 and it hasn't changed at all. The company has NO PLANS FOR FURTHER DELPHI DEVELOPMENT beyond maintaining their legacy code. They pay for maintenance updates, but so what? A couple of places I worked are extremely hesitant to allow any sort of large-scale refactoring -- they say if they wanted to invest in that amount of work, they'd just assume switch to rebuilding the thing from scratch in C#/.NET or something else -- not Delphi. WHERE ARE THE NEW PROJECTS THAT ARE CREATING MORE DELPHI JOBS? This is a MARKETING PROBLEM for Embt. I don't think they have any right to complain when they have steadfastly maintained a posture that has gotten them exactly nowhere in the market. There's no evidence that their products are being used for more NEW product development than to support LEGACY projects. Where's the beef? Or rather, Where's the NEW work? (And don't respond with, "well, we're doing new stuff!" If you are, say how many devs you've hired to help with the NEW stuff vs. to maintain the OLD code. Rather, show me, say, 10 job postings made to any of the popular job boards that are legit posts to hire people for NEW DELPHI-based projects. Nobody hires new devs for new Delphi work -- it's a reward given to long-time employees. The new-hires are almost always for back-filling open spots maintaining the old code. We've lost 3 people in the past 6 months who worked with Delphi, and I'm the only new-hire to replace one. Now Mgt is running around like chickens with their heads cut off because they failed to plan for this. Two of these guys left to work on stuff that's "more fun"; one non-Delphi and one is another legacy project but with some slow growth of new features. EVERYTHING I've seen in the past decade, or been contacted by recruiters about, has been MAINTAINING LEGACY CODE. I've found NO NEW WORK on Delphi, especially within 500 miles of where I live.)

depends on what? I'm curious what folks think when it comes to web apps vs. desktop apps.

I'd like to hear people's thoughts about this topic. I'm working with TMS WebCore and their MyCloudData to prototype something. There's a kind of utopian idea that you can "build once, deploy anywhere", but there's a fly in the ointmen that nobody seems to talk about. It seems to me that web apps come in two flavors: open and accessible to all that don't tend to save data; and everything else that lets you do stuff and save data across some notion of "sessions". The former might delivery kind of utility, like prettyprinting code or translating data from one format to another. The latter is what I'll generically refer to here as a "membership site". (Perhaps another terms is more appropriate; this is just how I think of them.) Historically speaking, desktop apps had no form of "login" -- they relied on the fact that there was a login on the computer, and assumed anybody who could get on the computer was permitted to access the software on it. This assumption still lives today on desktops as well as mobile devices. Which means you cannot simply take a desktop app that saves user data and drop it on a website to turn it into a web-based app. A lot of existing apps DO, in fact, offer if not require you to login, and there are a lot of reasons for that besides allowing you to keep your saved data separate from others. One big reason is to access walled-off services that require a paid subscription to allow access, for example. (At the very least, a registration is required in any case.) The thing is, the front-end or web-app could use something like OAuth2 to verify your login. If it's simply to gain access to some stuff kept behind a paywall, that's fine. But what if it uses your login to partition your data from everybody else? Back-end services typically have a login; in many cases, they're used by the developer or vendor to ensure nobody else can use the resource(s). For example, if my app uses SQL Server or MySQL, I have a login that all of my apps probably use to access my DBs. They may all share the same credentials. But they're MY credentials, as the developer. What about the users? How deep do you push the use of user credentials? The user could login just to prove they have a current account, then everything else could be done with MY (developer's) credentials. If you need HIPAA or PCI compliance, tho, I'm not sure that would fly. I'm wondering about this b/c I work in an environment now where user credentials go all the way down to the bedrock for desktop stuff. I'm not sure about our web tools, except they do require logins that are integrated into our single-sign-on protocols. I can see that a lot of services my software might access do not need to be partitioned for use by each user with their own credentials. But, in some cases, they might. So let's say you have an app and it requires a login to access and maintain some personal (but not very sensitive) data, then it can drop a cookie (in the web-app case) that, say, lasts a month. (I see this on lots of my phone apps.) The login controls access to some common data as well as a limited set of personal data. This isn't how Desktop apps normally work -- Windows or MacOS or *nix logins run the show in most cases. I'm not sure about mobile apps. Web apps designed like Delphi apps are still rather new. (Any IntraWeb users wanna chime in here?) But you don't design php or Wordpress sites as if they're Delphi apps. (In Wordpress, everybody gets a login, but the underlying resources all rely on a common access login. Strangely, it's common for membership sites that run inside of Wordpress to have a completely separate way of managing users rather than using the logic built-in to Wordpress. I think that's because the membership sites want more meta-data than WP can collect on its users.) What do you do when you can build web apps in Delphi that can look and feel more like normal Delphi desktop apps? (I'm not says they MUST or even should, only that they can.) Have you given this any thought? If so, I'd love to hear your ideas.

@stijnsanders and @Kas Ob. -- I appreciate the depth of your replies, but in this case there's nothing really on the server that's personal other than when a user subscribed, for how long, if they're still active, and their renewal rate, along with their first name, pwd hash, and email address. I suppose I could encrypt that stuff, but it's not particularly sensitive. However, the front-end needs to read some of it -- in particular, the FE needs to know if a visitor is a currently active subscriber, and possibly if their subscription is close to expiring so they can renew it. Is any of this a problem with GDPR? I do like the idea of validating using a 3rd-party login like FB, Twitter, etc., as an option. I'll look into that. I imagine it puts the onus of user validation on these other systems, right?

This is what Wordpress does ... which I addressed. Seems in your hurry, you have nothing to add. Better off just moving on next time.