David Schwartz

I have a small PNG that contains a signature sample, usually black on a white background. I do some processing on it and take a histogram to find the most frequent color (presumably the BG color) then set it as the transparent color, and assign it to another TImage. Unfortunately, it's still black on a white background. I want a way to see that it's actually transparent. Eg, if there's a checkbox and you toggle it, the background switches from white to, say, a checkerboard pattern. How do I set up the checkerboard pattern (or whatever), then how do I "overlay" the transparent image on it?

I don't know if you can run Delphi on this (maybe D7) but you can surely run small and modest-sized Delphi apps on it. Maybe even use it as a tiny web host for kiosks or demos. https://www.indiegogo.com/projects/chuwi-larkbox-world-s-smallest-4k-mini-pc?secret_perk_token=2ec0a2d6&fbclid=IwAR0cxLgK8Nm7pLcx04GdkAbwKtnuGw46UqG_k2irYqkARFn-h_ya6YhP42M#/ What would YOU do with one of these? (I'm just curious. I'm not involved with this in any way other than I love finding tiny computers.)

I can't really understand why people keep going on about version control stuff when the author has stated it's off-topic.... he seems to be asking about DESIGN approaches, like, eg., when you realize you need to split a class up into multiple pieces, not how to manage source code.

I was looking for comments relative to my statement that "it's a programmer error" vs. my colleague who disagreed and believes the programmer did exactly what was asked -- and no more. This is a constant problem outsourcing to people from certain countries / cultures because they're taught to never ask questions on the assumption that the person who gave you the directions knew what they're talking about. So to fill gaps in specifications that cannot be ignored, they just make stuff up instead of asking about it. It wastes time and resources, and leaves a lot of people quite upset. "Why didn't you just ASK???" is a common refrain.

The first ain't gonna happen -- that's not the business we're in. The second is one where we're not clear why it's not already available -- the only thing we've heard is "This IS the pre-processor" that's failing. Except it's also the front door to the entire process.

We don't currently do this, but it seems like it would be a nice alternative.

They have no way to reproduce the error. Simply telling them "it failed" isn't very helpful to anybody. So we end up spending quite a bit of time tracking down the issue for them. The problem is they rarely take corrective action b/c these data files are generated by an export routine on some app they're running.

So I guess I just put these two lines into a BAT file and run that? call "%ProgramFiles%\CodeGear\RAD Studio\5.0\bin\rsvars.bat" msbuild <project>.dproj (This is for Delphi 2007, for later versions, adjust the path to rsvars.bat accordingly.)

Well, all of the questions I found about this in SO talked about ancient versions of Delphi, like D7 and D2010. Nothing was very current. And I just followed what they said they were doing. I could certainly use msbuild if that's what's needed. This code we have started out in D6, and it has been very lightly touched since then. It does compile in Tokyo, and all of the files go to the current directory the same way they typically did in D7. The IDE is set up to do a Debug build and run. I'm simply trying to create an EXE invisibly if it's not there so I can run it for the user. (Users don't care about Delphi in this case; they want to run the app.) Please don't over-think this ... at the moment, I'm the ONLY user who'll be using this in the near-term. I just don't want to have to fire up Delphi to build the EXE if it gets deleted for some reason. (It's not considered "essential" and we have processes that periodically go thru and flush out non-essential things. In this case, the process says to run it within the Delphi IDE, which rebuilds it every time anyway. I'm just wanting to bypass Delphi.)

I get more Delphi-specific help online than I get from work colleagues. Have for years. That's the trouble in this business. I get hired because I'm supposedly a "Delphi expert" and they assign me to work with someone who teaches me how to use the crap process they have not changed in 10+ years because "the new guy doesn't know what he's doing yet". I make suggestions, and after a while someone pulls me aside and says I really need to "get with the program" and stop coming up with ideas about how to improve things and start learning the way the system works today ... because it's WORKING. Yup ... mostly ... except for the random errors and the blue-screens and the high-frequency of customer-generated errors that make our apps blow up ... My boss told me recently that I need to not be so afraid to debug stuff, that I need to roll up my sleeves and spend however many hours it takes working with the debugger to find input errors in an import parser. Our customers send us data files with a hundreds of thousands of de-normalized database records in CSV format, and sometimes they leave a new field name off the end of the header; or their system decides to render fields that are not usually zero as <empty>, as in xxx,,yyy,zzz... -- see it there between xxx and yyy? It just jumps right out atcha, don't it? This is the "New and Improved 2020 Digital Millennium Edition of Where's Waldo?" Waldo is hiding between those double-commas! Our code is fairly brittle and we get lots of error reports daily saying the Delphi apps crashed. The problem is that there are a ton of places in the import routines that call things like StrToInt(...) that throw exceptions when an input token is empty or not a numeric value. None of the fields are validated before we try the conversions, and our code doesn't have ANY Try...Except fencing around it anywhere. So all the exceptions get raised to the outermost layer of our framework that just re-raises them. My boss wanted me to get on a screen-share session with another developer to "see how it's done". The other guy said it took him about 90 minutes to track down the problem. Thankfully, I was busy on something else that had higher priority. When I was done with my work, I fired up Delphi, enabled madExcept, ran the same import routine and data, and found the errant line in less than 90 seconds. I made a short video of it with SnagIt and posted it for them. A company license for madExcept is less than it costs us to track down four or five of these import bugs, and we get one or two of them every week from clients. I'm trying to be helpful and show them how to waste less time, but of course they see it like I'm spitting in their faces. People are so effing weird... So don't think you're missing anything by working alone. Most of the folks in this forum can answer questions nobody else can. They get tired of me asking what must seem like dumb or repetitive questions, but that's another matter. It's better than asking colleagues who don't even understand what I'm asking or insist I forget all of that "expertise" they hired me for so I don't make them all look so ignorant. Anyway, I can't tell if what I posted was helpful since you went off on a meta-discussion... As for this comment ... I think you're missing the point entirely. TMyClass = class . . . end; This is a class. It has nothing whatever to do with frames. TMyForm = class(TForm) . . . end; This is also a class. It also has nothing whatever to do with frames. As far as "flexibility" goes ... they're CLASSES ... you can make them do ANYTHING you want! Frames are also classes. So what? So are TStringLists. You're confusing language constructs with magic pixie dust that the IDE provides you in a few random cases. I've seen Frames implemented without help from the IDE and they are butt-ugly and not half as useful. I'm talking about CLASSES... some of which are derived from TForm. The way you interact with TMyForm should be no different than how you interact with TMyClass. That's all I'm saying. People nod their head as if they agree. But they don't. Not really. Most Delphi devs will happily go on and on about the proper ways of interacting with classes (in general), and then proceed to throw most of that lecture out the window when it comes to interacting with Forms. Go figure...

Without looking at something specific, it's hard to comment on this. I think the version control thing is off-topic, but I get how people see it. What I'm hearing in this question is "how do you handle design evolution?" I typically start a new project with a general idea that begins with a single form and unit. It's not like I sit down and map everything out first, although sometimes I do. Many times I use Delphi as a prototyping tool, so I'll lay down different ideas in different "apps" just to see how it "feels" from different starting points. Also, if there are different specific "functional units" (I use the term loosely) then I might flesh them out as separate little apps, but build them in a way that the main form acts as a stub to drive the main logic in a separate unit. Sometimes it all starts out in one unit, then I migrate a chunk out into a separate unit that can stand alone. FWIW, in general it's not possible to use a "main form" to build something you want to add to another app. There are things needed in a "main form" that are never found in standalone forms, so if you know you want to build a form that's going to be used in another app, start with two forms: the main form and a second one where you'll explore your new idea. In many such cases, the main form is just a form with a button "Open Form2" or whatever. You set up context in the main form, then call the new one you're developing. That said, I'll often add new stuff to the main form until it begins to take on a clear shape, then move that code into a separate unit, either as a separate (non-visual) class or a separate (visual) form, depending on the need. For apps that have lots of forms, your main form becomes more like a launch pad for everything else, like the foundation of a house. Part of it may end up acting like a traffic cop, using different forms / units to support each menu event. If you have to support "settings", you'll typically manage them in the main form somehow, but it's best to keep them in a separate class / object instance that can be passed around rather than having other units just reaching into the main form for stuff (causing circular references). Sometimes it helps to pass a reference to the settings object to new forms as a common input parameter when they're created rather than a litany of separate variables. (Eg, input_folder, temp_folder, output_folder, input_fname, output_fname, username, userid, permissions_level, blah blah blah...) Settings are also commonly saved in an INI file or in the Registry rather than a standalone "settings" object. That means that if you want to ensure reduced coupling between units, you'll pass in the name of the INI file or Registry keys when the form is created. Again, people frequently get sloppy here and since the programmer "just knows" these details, the code becomes littered with unconstrained accesses to INI or Registry data that can lead to headaches down the road. It's best to create a wrapper class around whatever you use so if you decide to move it from say an INI file to the Registry, then perhaps into a DB, you only need to change it in one place. (The place I'm working now has such strict security crap in place that we developers cannot even run RegEdit! We can get limited access through a wrapper, but things like Delphi's settings are considered "sensitive" and we can't get access to them! Our programmers are returning to using INI files for small localized stuff, and use the DB for more extensive and production-related needs. Existing code needs to be migrated to bypass the Registry, and it's no small feat when there are dozens of direct accesses to Registry entries scattered throughout the code base. If these were all put into a single TAppSettings class from the outset, we'd simply need to change a couple of local methods and viola! Everything would be switched over.) I'll frequently start out putting common functions in the main form, but at some point they get moved into a separate unit to avoid circular references. It helps to remember that "forms are classes" and the same rules that apply to classes apply to forms, although it has been common for people to forget that and they end up with quite a mess as their project grows. I think of forms as "visual classes" and treat them the same as any other class: you need to instantiate them, set up initial values, fire of their main "do_something" method(s), get back results, and then dispose of them. Maybe you decide to have them created automatically at start-up and leave them "open" all the time, but that can be dangerous and leads to lazy coding practices. Treat them the same way you treat classes and your life will be much easier as your app grows. Does this address any of your concerns? Or am I totally off-base?

These religious debates are always such fun ... 😕

I have an oddball multi-media question. Here's a list of ingredients I'm starting with: * 50 Powerpoint slides (one per file) that contain some text with animated fly-in * 50 background images for use with the PPT slides (the images are already paired with slides to maximize the visual effect of the fly-ins) * 50 or so 30-sec MP3 audio files * 200+ inspirational messages The idea is you take a PPT slide; change the background image if desired; then change the text to one of the inspirational messages. Then you drop in an audio file that can be triggered to start playing when the slideshow begins. For each of these composed slides, you use something like Camtasia to record the slide playing in PowerPoint with the music for 30 seconds or so, and save it as an MP4 video file. I'm curious what would be involved if I wanted to make a program that creates these videos from different combinatins of the ingredients so I don't have to do them manually or hire someone to do it for me. Obviously, there are thousands of different combinations, although they're mostly limited by the quotes. But there are hundreds upon hundreds of different quotes that could be used. I don't suspect Delphi is the first language or platform someone would try making such a program in, but maybe there are some libs or components that would make it pretty easy. Anybody have any experience with things along this line who could lend some insight? (I'd guess Shockwave would have been a good choice 10-20 years ago, but not today. I'm not sure what other tools might be available, but maybe some stuff with API access?) Would it be easier to do using, say, HTML?

If that was the answer, then neither Apple nor Google would be investing in the development of "Car-play" and similar platforms that are designed to extend and even replace the crapware that car manufacturers install at the factory and never update. What benefit does BT offer to me if I want to have Google Maps show up on my display rather than the junk built into the car? My car has BT, but so what? It's only used for audio and alerts from my phone -- yes, including text messages! Don't ask me why because it doesn't show them unless I'm parked, in which case I'm not going to bother reading them through the car's screen. BT is a data channel. That's all. WiFi is higher bandwidth, but nobody has seen fit to built it into a vehicle's core yet as a way to replace the CAN plug. Maybe they're concerned about little things like security and privacy? It would be a heckofalot easier to have an open WiFi connection for cases like Uber/Lyft drivers who've got passengers who want to connect their phones to the car's audio system. When I did that for a while, and kids would get in and want to connect via BT, it typically took half of the ride time just for them to get everything to connect. After a few times, I just told them, "Sorry it ain't happening". Sometimes they'd get in and have an aux cable they wanted to plug in. I'd just say, "Nope, someone broke my plug. Sorry."

Sorry, but I've seen many that are simply largish-screen monitors (24"-27") with a small computer attached to the VESA mount on the back. I see these in banks, places with self-help customer services, and similar places. You're thinking of "old-school" things. Not that they don't exist, but this is a popular use for NUCs. As for the "reliability" question .... I once had a contract to do some evaluation of COTS stuff for a military outfit that was wanting to know about the reliability of COTS vs. similar "mil-spec" boards. It surprised them to learn that some COTS boards they were considering actually had better reliability metrics (except for one thing that was easily resolved) than their comparable mil-spec devices, at 10% of the cost per unit. They decided it made sense to order 3x more of the COTS products and maintain a larger inventory of spares rather than order more mil-spec devices. They also expanded their search for qualifying COTS devices as the cost-per-unit was so much lower. In certain applications, you want ruggedized hardware to minimize the risk of random failures at times that would be hard to get replacement parts. But there are situations where it's simply overkill, and making replacement parts available is far more cost-effective than using fully-ruggedized devices. If you have a data collection device out in the middle of a corn field that's supposed to relay data every 5 minutes, and it would take more than a couple of hours to replace, sure, use something more rugged. But if it's sitting in an office with A/C and heat and there are people constantly there who can recognize a failure and address them when they happen, then it's probably cheaper to go with something cheaper and have spares in the back room. Then again, if Management prefers to hire people for minimum-wage and give them the least amount of training required, then the equipment is probably regarded as more reliable than the people, so that approach probably isn't viable for them. At the end of the day, like most things, it's a trade-off. My employers give me Dell computers that are notoriously unreliable, both the hardware and Windows. But they seem to prefer them over Apple for whatever reason. I've been using Apple hardware since 2006 for my own needs, and have had far fewer problems than the equipment given me by employers. Yet how many times do we hear people say they think Apple's stuff is just "toys"? I guess it's all a matter of perspective.

If they're so concerned, why did they do away with interface controls that you could touch and adjust without having to divert your attention from the road to their "touch-screen" interface that reacts to the slightest whisk of a finger and leaves no clue what you touched or how you ended up where you're at? Nobody is ever going to convince me that a UI that is touch-sensitive and doesn't offer any way to do things without looking at it is in any way "safer" than one that does. The map won't let me edit anything while the car is moving, but if I'm using it for navigation and I happen to brush the screen, it can change state and get messed-up and I have no idea what I did or how to get back to where I was. It connects to my phone and tells me I have a new text message. It forces me to divert my attention from driving to focus on the screen long enough to press a button, and instead of simply reading the text message to me (via text to speech), it displays a message on the screen telling me it cannot show me the message while I'm driving! What kind of idiot designed this and what committee decided it's a "safe" design? Google lets me use my voice to find a destination; the car's nav forces you to enter everything via the touch-screen starting with State, City, address or name. It's effing worthless IMHO compared to what I can get on my phone with a couple of voice commands and touches. I'm sorry, but the current crop of touch-based UIs is far more dangerous than using my phone. Yet states are passing laws to prevent people from using their phones instead of the more dangerous crap that car manufacturers are delivering. Not because they're designed to be safe, but because they're designed to be flashy and make you hope you don't miss your far more flexible mobile devices. Never mind that most people upgrade their devices yearly, and vendors are constantly tripping over themselves to add new features and make them more and more useful. Compare that to car manufacturers who basically design what's in a car 2-3 years before it goes on sale, and IT IS NEVER EVER UPDATED! Unless, of course, their horrid UI ends up causing so many crashes that the resulting lawsuits force them to do a recall and issue an update. When I took my car to the dealer for an oil change recently, I asked the service manager when I can expect Toyota to download a software update to the car to improve the battery life and efficiency, the same way Tesla does it on a quarterly basis. He just gave me a blank look and shook his head.

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!