David Schwartz

That's what I'm asking about... If I have a script in the document root that loads up a little table that has a filename or URL plus a timestamp of when that page should be displayed, can I simply load the page from a file or the URL and simply send it to the browser without worrying about anything else? For example, if I put a Wordpress site in a folder beneath the document root, then let the user access that to create the pages. The little table used by the script above it would simply need to find the URL to request from the WP site based on the current time vs. times in the list, and then load it up and send it to the browser. The whole purpose of this is to have a mechanism separate from the platform to manage time-based displays of specific pages, which is not something that Wordpress or any other platform I know of does easily. The guy who created this whole model has it implemented on InfusionSoft / Keap and hired one of their consultants to build the whole site for him. The page sequencing is fairly trivial, but there's no Wordpress plugin I've found that does that. It's sort of antithetical for how most websites work. (Typically, you post a page and the site displays it. There's no notion of "sequencing over time" for the same page URL. In fact, it's quite counter-intuitive. But for this application, it's required.) Analogy: you go into a resturant and they have a daily special that's different each day. A web site works by having a different room you'd go into for that special. But you only want it open on the day that special is being offered. Which means you'd need seven different rooms to handle daily specials each day of the week. That's silly. You just list them by day and you order the "Daily Special". The kitchen can't fix the other ones if you were to ask. That's like a URL in this case -- same URL, different thing served up based on the day. Websites don't work that way.

EUR and USD are almost equal right now. I was paid $32k back in 1982. Current salaries are around $100k, and even really cheap Delphi devs are $70k. Full stack web devs are up to $150k. Delphi is a "full-stack" tool, but nobody seems to regard it as such. 🙂

Well, I'm concerned about the "page editor" and dependencies that may be in the HEAD section that may need to be changed. I use "page editor" loosely because it could be just about anything, and could also be done in Wordpress to create the requisite pages. What I want to create is a generic tool that doesn't care what's used to create the pages. What it does is looks at the current date and time and then determines which page to display. I was thinking the page would need to be loaded and partially parsed so the header can be tweaked, but upon further thought, that's probably not necessary. Can I just load a file or URL and send it to the browser as-is?

If you create a class for this, then there's a method that can theoretically create an instance of it and fill it from a chunk of JSON data: var data_obj := TJson.JsonToObject<TMyObj>( req.Response ); In this case, the JSON data would go into a class TMyObj, which is the type returned in data_obj. I've used it for simple objects, but I'm not sure how it would handle lists and arrays. BTW, that JSON has an error in it -- a dangling comma

I'm building an app that uses a REST API. The API itself is rather simple. There are a dozen optional parameters that you can send to a few of the endpoints as 'xyz=<boolean>' where <boolean> is a string of either 'true' or 'false', along with a few parameters that take one of a few strings or a number. I created a unit with API-related methods in it and it's called from the main form when needed. That much is working with default parameter settings. Now I want to add a simple way to let the user select API options and have them passed to the API unit without the API unit knowing anything about the UI, and without requiring a ton of arguments on one setter method or a ton of properties to set every possible parameter. (These are all inputs to the API calls; the output is a JSON packet.) The app right now is a VCL app, and it may change. I have created a Page Control with several tabs that have checkboxes on them with an explanation next to each one that says what it's for. I made the caption on the checkboxes the same as the name of the API setting, like 'xyz' above, with the thought that I could use it somehow in the settings if I collect the components into an array. The challenge is that you need to clear parameters before each API call, and add a few locally (URL, login name and pwd) that are buried in the API unit. (I suppose they could be moved into the Main unit if it helps.) So when I call the API method, it calls an internal method to clear the Parameters, adds the URL, login and pwd params, and its at THIS POINT where I need to add the OTHER params selected by the user on the UI side. Then I call RESTRequest.Execute and wait for the response. I can think of several different ways to do this, all of which are fairly convoluted and inelegant. Even if I just have a bunch of setters that need to be called, I'd need to pass in a callback method that's called to add them to the list of parameters at exactly the right point. All of the examples I can find tend to be very simplistic, mixing the UI and the API calls in the same unit; I'm trying to keep them separate, but SOMETHING needs to be used to get the values from the UI elements and either save them for later, or inject them directly as parameters into the POST call at the point where it's being created. This would seem like it would be a fairly consistent pattern when you have an app with a UI and one or more units with API-specific logic in them, and you don't want to have the API units having to know anything about what's in the UI, yet it needs to include the values of settings made in the UI at a place in the logic flow that's quite inconvenient for the API's client to access. I'm curious if anybody here has come up with a clean and fairly simple solution to this problem that they'd care to share?

If that salary is in USD, it's horribly low.

I don't know what PAS 21 might be, but I run VirtualBox on three different Macs, two of which are running 10.14 (Mojave) and one is running 10.15 (Catalina). The VM has Win 10 and Delphi 10.4.2, and it runs just fine. All three machines have at least 16 GB of RAM. How much RAM is in your Mac?

hmmm ... yeah .... you need to type a LOT of stuff that should be available at the click of a button, given a few clues. I discovered there's a function in the JSON library named JsonToObject that I thought initially would read a JSON packet and generate a class then fill it with data. It turns out you need to define a class yourself, then pass it a JSON packet and a class reference; it will read the JSON, create an instance of the class and then fill the fields it finds that match -- which means the fields need to have the same names as in the JSON field names. This is a fair trade-off to me. (The class can have other stuff as well; that method just looks for fields in the JSON file that match in the class definition and copies the values over. I haven't tried using lists or arrays or things like that, so I'm not sure how it handles them, tho.) It should be that easy!

I've decided to just have a callback method at the point where the parameters can be added before calling the API that sends a stringlist with the names of the parameters that particular call can accept (eg, <name>), and it gets back '<name>=<value>' for each <name> in the list. This is as opposed to what I typically see which is a long list of .AddParam( 'somevar', Form1.Edit1.Text ) calls that reach back into the UI unit (eg, Form1) and grab the values from the Date/Edit/Checkbox/Memo fields directly. Why should the API unit have intimate knowledge of what's on a form? As much as people love to talk about the principles of OOP, it baffles me that so many Delphi programmers still seem to toss all of that out the window when it comes to Delphi Forms. It's like, "Oh, Forms ... yeah, they're objects, but ... meh ... it's too much trouble to define properties and DI and stuff. That 'encapsulation' nonsense is for library files, not our own units."

This is a great interview with Anders Hejlsberg done recently. I learned a few things I didn't already know about the history of Delphi and why certain things in the programming world evolved the way they did. Anders has a very unique perspective from working at both Borland and Microsoft for as long as he has. I'm guessing that Anders is a few years younger than me from what he said here, and I can certainly appreciate the value of being able to look back on 40+ years of an industry that you watched get born and grow up.

I've been looking into what it takes to build a cross-platform app that's mainly audio-based. Each platform has its own set of media interfaces and logic, and stuff that works on Windows doesn't translate easily into what any other platform uses. A common framework would help a lot, but it's a lot of work to build and maintain. Someone pointed me at the Web Audio API (WAA) for web browsers; it's a javascript library that's been around now for most of a decade, and it's supported fairly completely by most of the latest browsers. An excellent book was published earlier this year about it that can be found here: https://www.routledge.com/Working-with-the-Web-Audio-API/Reiss/p/book/9781032118673 I'm guessing this is being used in a college course by the professor who wrote it. I ended up getting some help from Andrew Simard who has been writing a series of Application Notes for TMS WebCore that have been posted on their blog. I gave him a couple of suggestions for demo apps which are hardly trivial, and he dug into both the UI side and the logic side, creating a couple of rather amazing demo apps. What's most amazing about them, in my mind, is that they run inside of the browser, and therefore on pretty much any browser and platform that supports WAA. I invite you to take a look at the two articles and see what Andrew was able to accomplish using TMS WebCore on one side to implement a lot of the logic in concert with the WAA library on the other side -- which is all the more amazing since it's all in javascript. The UI side is all in HTML and CSS, written in WebCore / Delphi, and there are numerous events that are generated on the UI side passed back and forth between the Delphi side and the javascript side. The second post has a link to a live example; perhaps Andrew will add a link to the first post as well. Here's the first article: https://www.tmssoftware.com/site/blog.asp?post=999 and here's the second article: https://www.tmssoftware.com/site/blog.asp?post=1003

Hardware encryption needs to operate differently. This makes total sense.

I've worked with a few Samsung T-5 drives and they come with encryption software on them. So do lots of thumb drives I've gotten over the years. The files are usually in a folder and there's a READ.ME file and info about how to use it. I've not seen one that mounts up as two devices, tho. That would always work. I'm curious what devices you're referring to that do that. The encryption would be on the memory device, but the CD device would be unencrypted, but probably flagged as read-only. You should be able to see it but not erase it.

The first thing I do when I get a USB memory device that has encryption software on it is I reformat the entire drive. I've never looked at that stuff, although I did notice an autorun.inf file on one device. I've not noticed any that show up as CD drives, tho. If you say they auto-run, I'll take your word for that. (These things I looked at actually registered with two USB IDs: one was a read-only CD and the other was a r/w memory device. The system would look for the autorun.inf file on the CD partition. I think that's how they did it, but you can't simply partition the drive; the device's logic has to respond as two distinct devices, probably as if they are both connected to a hub. It was 20 years ago and the details are fuzzy.)

It's a convention added to Windows to get CDs to auto-run a setup.exe when you inserted the disc into the drive, as opposed to booting from it. When thumb drives hit the market, you couldn't even boot from them until vendors added that into the BIOS. But it was still problematic to make them auto-run something when you plugged them in. Some vendors added a setting into the BIOS to enable that, because it's a big effing security risk. Why run anti-virus stuff if someone could simply pop a thumb drive into a USB port and have it inject something into the computer without ever displaying something on the screen or tripping the anti-virus stuff? USB ports are (were) problematic for AV scanners because they had to figure out what type of device was connected, if it had any storage, if it made sense to scan it ... how does a memory device differ from a LAN adapter or a WiFI adapter or a serial port? At least CD readers don't change their character, but USB ports do.

There was a time where I did C++ almost exclusively for about 10 years, then Delphi came along and I transitioned over to it instead. I played with CPPBuilder a few times and found it far more verbose than Object Pascal, although I think, generally speaking, OP is more verbose than C++. It was the way the VCL was set up and accessed through C++; it just struck me as extremely convoluted. I've hardly looked at C++ in 15 years, and recently looked over the latest C++ standard ... boy oh boy ... they have added so much "bling" to the language that it's nearly impossible to read the code! It looks twice as verbose now as before! There was a lot of stuff that you had to learn that was idiomatic; today, so much of that has been made explicit through "attributes" and callouts of library options and so much gnarly stuff. I wonder if code from 1995 will even compile and run today? I know Delphi1 code probably will. Anyway, I'm thinking you might be a lot better off translating those C++ units into Object Pascal, mainly because you wouldn't be stuck trying to find someone to bridge these two langauges even though they're still more-or-less integrated into the same IDE. I'm not aware of anything that can be done in C++ that can't be done in OP.

This was a holdover from CD-ROMs. It's actually a really hairy securitiy risk. You had to go into the ROM-BIOS of the machine and enable a setting to run it, but I'm not sure that even exists any more. At one point, I was looking at something that did that predictably and found a company in Japan or S. Korea that made thumb drives that registered themselves with Windows as CD-ROM drives, thereby enabling the autorun.inf to be called. I got some demo devices for testing and they worked as advertised, but that project ended up not proceeding. A year or so later I happened to check back with the company and they were no longer selling those devices. I've been in many places where their IT Dept literally disables the ability to mount any sort of external memory device via USB to their computers. That does not keep you from transferring files, it just makes it a bit more convoluted. (This is where being a Windows programmer comes in handy!)

I'd suggest you start out building something simple. Building something that can be wrapped in Miletus is probably the most complex thing you can start with. It's like someone says, "I want to learn Delphi; I'm having trouble getting the web service to work on a Linux server that my app needs to run." They have a support forum that you should be able to join and post questions. Also, check their blog for examples.

I was diagnosed with Asperger's last year and it explains a whole lot of strange things going back to childhood. One is that I tend to be very wordy. I cannot comprehend how folks can say anything useful in ten words or less. For most of my life, I just avoided saying much because I'd get so much crap for it. But since being diagnosed, I've come to embrace it. Yes, there will always be people who get annoyed. I envy them for their ability to be brief. A common complaint I've heard over the years is something including the words "over-analyzing" or "over-thinking" things. Asperger's is said to be a form of autism, and one thing that characterizes the autistic brain is we tend to be dealing with 10x or more stimuli coming into our brain at any given moment that most other folks. Here's an analogy: In baseball, you can be standing at the plate, and for most people at bat, they just see the pitcher, the wind-up, and then a ball coming at them. They can focus in and just see the ball. And they have to make a decision when the ball is about 1/4 of the way towards them whether to swing at it or not. I see the ball, the pitcher, the second baseman slapping his glove, the short-stop stepping sideways, the left and right fielders getting ready, the 3rd-baseman, the 3rd-base coach signaling the guy on 2nd base, the birds flying at the lights, some people in the stands jumping around and waving, and I hear all of the noises behind me and coming from the dugouts. Sometimes it's a wonder I can even swing the bat before the ball is in the catcher's mitt. I loved basball as a kid; I played left field, and I could stop anything coming at me. But I could never hit the ball worth a darn, so the coach would only put me in on the 7th inning. When I hear those words, "over-analysing" and "over-thinking", it reminds me that most people have brains that allow them to just focus on the pitcher and the ball, without all of that other crap distracting them. For THEM, they'd have to think long and hard to be present to even a fraction of the "noise" that floods into my head every waking moment of my life. For THEM, it WOULD take a LOT of analysis and thought! For me, it's just what's there when I look at ANYTHING. It's like ... human beings have a "squelch" control in our brains that's set to only allow the strongest and most intense signals come through to our brains. But people on the autism spectrum have that squelch control turned down so we get a lot more noise along with the signals we're looking for. And we have to process all of that crap in real-time just to stay focused on whatever it is we're trying to deal with. People on the so-called "lower-functioning" end of the spectrum have it turned WAY down, to the point where they can't talk or control their muscles well due to the constant overload of signals coming into their brain. At least, that's one of the latest theories. It seems to capture some of the dynamics involved, anyway. It's a big plus in the software field because it helps me be a great architect -- I naturally see things from a birds-eye view, and often with far more breadth, depth, and detail than most other folks. Of course, they all think I'm off my rocker and say things like, "Earth to Schwartz ... come on back to the meeting!" I cannot tell you how many problems I've seen over the years that nobody wanted to talk about that later on came back to cause major problems. It's both a gift and a curse. It's just how my brain works.

Since 1999, I've been hired numerous times because I'm an "expert" with DELPHI -- not merely with Pascal. I have never been asked about either FPC nor Lazarus for use in any sort of production capacity. They have language features that Delphi only dreams about, and they can be fun to play with. Even an educational institution I worked at for nearly 5 years kept their Delphi license current and the project head refused to even consider FPC or Lazarus. Lately I've been shifting my focus over to TMS WebCore because I believe the future lies in web apps for generalized cross-platform needs, rather than a hodge-podge of separate platforms that are all evolving so fast that keeping track of them all in parallel with moving the common platform forward is an expensive exercise in chasing one's tail just to stay current. TMS has also added the ability to encapsulate WebCore (or any web-based) apps to run as native apps using their Miletus technology. Is this a panacea for all of the humonguous apps historically built with Delphi that have been around for more than a decade? Hardly. But the last three jobs I've had all implemented a ton of stuff in core parts of their systems that could be moved without too much trouble into service-based instances running inside their own network. One was slowly moving in that direction for newer things, but I saw a ton of resistance elsewhere. An earlier one was migrated from one DB to another. I know we could have done it in-house in about 4 months, but upper Management insisted they thought it would be better to outsource it. I have no idea what it cost, but probably over $500k, and it ran over by 50% before they pulled the plug and the other dev on our team finished it up in a few weeks. The whole thing could have been reimplemented in far less time as a REST-based service, but everybody thought that was just way too risky and that the performance would be really bad. They were just guessing, of course. The bottom-line is ... Management sticks with what they know. From what I've seen in most apps I've supported, there's a ton of stuff that can be easily factored-out and moved into REST-based services. There's also a lot of UI redesign that can be done to simplify different use-cases. What happens with these big desktop apps is they start out simple, then get warts added on top of warts until you have this huge, complex mess that's got all sorts of right-click options on virtually everything to deal with common needs that cannot be provided without severe change to the UI. Moving these horribly mutated ginormous desktop apps over to web apps without significant redesign is silly. But it's all that companies seem to think is warranted. Either that or it's like: "well, if we're going to rebuild it, there's no way in hell we'll use Delphi! We'd only consider C#/.NET in that case." I have personally never seen a single one of such redesigns ever completed on-time or within budget. So I'm not doing Delphi work any more, because pretty much the only jobs I get hired for are maintaining ancient legacy Delphi apps where the company generally refuses to allow us "experts" to do any sort of refactoring. (I have always suspected that's because they usually have no automated test suites.) I honestly don't even know why they bother to hire Delphi "experts" because they never wanted to hear anything I suggested. My job was to simply fix bugs reported by customers and add the occasional feature that a customer pestered them to add -- and often paid for. All that to say, I don't think this has anything to do with "Pascal" at all. They know "Delphi", not "pascal". But if they were to switch, they'd rather switch to JavaScript, Python, Rust, and Go. Even C# is fading away.

At some point, I plan to hire a seasoned Delphi dev for a project. It involves building a web-app using TMS WebCore and a back-end service to support it. There will be three parts: the client-side logic, client-side UI, and back-end services that will use several TMS Biz libs. Learning to work with WebCore for the logic part is not a major conceptual jump for most Delphi devs, as well as basic (out-of-the-box) UI design. As for the client-side UI part, WebCore has its own components and you can also use the TMS FNC components for the UI widgets, as opposed to VCL or FMX widgets. I find them easy to work with using the default settings. However, they can be tweaked using javascript and HTML. WebCore also lets you import most any javascript library, including GUI libs, and I'm planning to use a couple of non-GUI js libs so far on the client side. I'm far from a js expert, and some of these libraries make my head spin. So I'm wondering if I should also plan to hire someone who's got experience working with a variety of javascript libraries (particularly the ones I'm considering using), and expect them to learn enough Delphi to work in the IDE (either Delphi or VS Code) to help with all of the client-side javascript integration? I'm sure this situation is not unique to Delphi and how TMS WebCore work. So I'm curious how others have made this sort of tech mash-up actually work in a real project environment? The client-side logic could be done in C# with UI libs in the MS variant of javascript. The same issues will arise, right? Would you hire an experienced JS dev? Or just have the Delphi/C#/etc dev learn enough JS to make it work?

errr ... WebCore runs pas2js and translates the Delphi code into js. The "clever" part is being able to code in Delphi, not the fact that the runtime is 100% js and it can work with virtually any existing js lib you can find. What I need is someone to write a couple of classes for me in js that use another js lib, and then I want to access that lib from the Delphi language side as PODOs. The underlying library I need to use has some functions that use multi-threading to do things. I've been trying to do the multi-threading at the Delphi level, and it's just gnarly. I'd rather have a couple of classes to abstract out what I need at the Delphi level, and just let them manage things natively at the js level. There are already a bunch of popular js libs imported into the framework that can be accessed on the Delphi side. That's how things work if you want to extend WebCore the same as adding components and libs to normal Delphi.

have you considered making a helper method? Or a subclass? It really doesn't matter all that much, but they should be set together, not separately, IMHO

It's a web app, written in Delphi using TMS WebCore. I can do that myself, but I'd rather hire someone to do it. You asked "why Delphi"? This whole project is like mixing oil and vinegar. I know Delphi and I know WebCore -- the "oil" part. What I don't know much about is the javascript and HTML that controls the UI in the DOM -- the "vinegar" part. I'm also at a point where I want to stop doing everything myself and coordinate a team that's doing the work. I can hire a Delphi dev, or do the Delphi part myself. Either way, the Delphi part is not the problem I'm facing. WebCore uses pas2js to translate Delphi into javascript and it packages it up so it runs inside of the web browser. This opens it up to the ability to interface with other JS libs and functions wrapped up in a way that they look and act like plain old Delphi objects. As it happens, there are a bunch of properties in both the WebCore and FNC UI components that let you insert HTML tags to fiddle with things inside the DOM. I don't have a good understand of that side of things, and I'm not sure how many Delphi devs do either. But folks who work with JS know this stuff cold. I don't need help with the Delphi part. What I need help with is the javascript stuff, and someone who's adept at those HTML tags that need to be set in the UI components to fiddle with things in the DOM. It would be nice if I can find a Delphi dev who understands WebCore enough to make sense of this. But the javascript part is still way off in the weeds for me. The JS person doesn't need to really know much about Delphi other than how to set and edit those HTML tags in the IDE's property editor. THAT is something that can be learned in two minutes as it's not unique to Delphi's IDE. All that said, have you ever sifted through a pile of resumes for Delphi devs looking for people who can do low-level and back-end stuff, and you get a bunch of "form jockeys" whose entire Delphi experience is making hundreds of forms by dragging-and-dropping the fields from the little box that appears when you double-click a TDataset in the IDE, onto a form, and then moving the fields and captions around so they look nice? That's what I'm getting as far as people who claim to know UI programming with javascript. I don't know much about js, but these people who are looking at my job posts can't even ask intelligent questions about my stated requirements. Would I be better off just having the Delphi person learn javascript and slog through figuring out the JS side of things?

This really isn't about Delphi. WebCore is easy to work with and is quite adaptable to JS widgets and frameworks. I don't think that using something else to build the UI part isn't going to save me much time. That said, given a moderately complex mobile front-end (UI) app design, do you think it would be quicker in Delphi + WebCore; JS + some IDE; or something else entirely? What I'm having trouble with is finding someone who knows javascript for more than simple UI interactions and can build a non-UI library on top of another JS API lib that I need to use. THAT library they create can (supposedly) be integrated into WebCore fairly easily. It can also be accessed through HTML5 tags with appropriate parameters -- these are simply properties in the IDE that can be edited through a string property editor. The only Deplhi someone needs to know is about as complicated as figuring out how to edit similar properties in Photoshop and other IDE-based tools.