Jump to content

David Schwartz

  • Content Count

  • Joined

  • Last visited

  • Days Won


David Schwartz last won the day on February 19

David Schwartz had the most liked content!

Community Reputation

104 Excellent

Technical Information

  • Delphi-Version
    Delphi 10.3 Rio

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. David Schwartz

    Minifing HTML

    Aside from the tags that cannot be replaced, and the text that you want displayed, I'm not sure what you can remove. It's not like javascript where you can change all of the variable names to 2- or 3-letter codes and remove most of the white space. What do you imagine can be compressed out?
  2. I think the problem you're going to run into is in how the RTTI support changed massively in D2010. Legacy apps built before that aren't going to care. But most libraries since then have come to depend heavily on it for a variety of things, especially when it comes to offering services of many kinds. There's stuff that simply cannot be done in D7 or even D2007 that can be done with the new RTTI support in D2010 and fwd. A lot of these have to do with design-time support as well. So you can sometimes find libs that have run-time support back that far, but not much design-time support. A straightforward REST/JSON API shouldn't be terribly difficult to write, unless you want to be able to send objects over the wire and have them reconstituted at the other end. Short of that, you might find something that works for you.
  3. David Schwartz

    where to find Konopka Components for Rio?

    Sheesh ... for anybody else looking for this ... they renamed it to "Bonus KSVC" within GetIt.
  4. I'm trying to load up a project that uses Konopka Components from a Tokyo project into Rio, and I can't find this library in Rio's GetIt. (Rio 10.3.3) I see people complaining that it was missing in the initial release, but ... is it still MIA?
  5. David Schwartz

    'stdcall' for 32-bit vs. 64-bit?

    Thanks, but in this case, I'm only dealing with Windows and two versions of the same DLL -- a 32-bit and a 64-bit version.
  6. In my mind, "initializing the car" is mostly focused on getting the engine started and ready to drive. There are all sorts of pre-checks that could be performed, like pilots do on aircraft: tire pressure, chalk-blocks on tires, garage door, main gate, parking brake, fluid levels and brakes, lights, windows, A/C or heat, defroster, etc. So to a certain extent, the analogy breaks down. Personally, I'd say the "base class" initialization is just what's going on "under the hood" and everything else delegated to a derived class, or the driver, depending on how much of it is automated. You say po-TAY-to and I say po-TAA-to. It's not worth arguing over. 🙂
  7. David Schwartz

    'stdcall' for 32-bit vs. 64-bit?

    I ran Dr. Bob's HeadConv to convert several .h files for a DLL to Delphi, and it sprinkles these IFDEFS into all of the function calls. They're needed for older 16-bit stuff, but I haven't run into any in years. It's mainly that I wasn't sure about 64-bit needs. Glad they're no longer of any use in 64-bit mode.
  8. David Schwartz

    'stdcall' for 32-bit vs. 64-bit?

    for DLL importing, there are lots of {$IFDEF WIN32} stdcall {$ENDIF} constructs I'm seeing. I'm thinking this is for distinguishing between 16-bit and 32-bit library calls. What about 64-bit? Do you need 'stdcall'? Or something else? Or nothing?
  9. perhaps it's a poor choice of words. Usually one would construct an object, and when it's fully constructed, it can be used. Values can be injected via the ctor's Create parameter list. Sometimes this isn't possible for various reasons. In that case, Create would build as much as it can, then you'd use property or method injection to initialize subsequent values, then proceed to work with the object. The benefit of injecting values in the Create parameter list is that once the Create finishes, you're supposed to have confidence that it has been properly constructed if it doesn't throw an exception. When you use property or method injection to perform further required aspects of initializing the object, that's not necessarily the case, as there would be one or more methods in the class that would not work properly if these further initialization operations are not done first. This is distinct from simply setting state variables in the object to alter its run-time operation. Here's an example that could go either way, but take it in the spirit it's being offered... When you start your car (ie, initialize it), it's ready to go. You can put it in gear and just drive off. But there's a step that most older cars require that newer cars don't, which is "check need for headlights". If it's dark outside, you can drive the car away without turning on your headlights, but you risk running into something, or getting a ticket. Said another way, there's a high potential for a run-time exception to occur if the lights aren't properly initialized. So there's a secondary initialization needed where the driver needs to make an observation and then turn the headlights on before driving away if it's sufficiently dark outside. Newer cars have put sensors in the vehicle that automatically turn on the headlights when the ambient lighting drops below some predefined level. So this way, no further action is required -- you can indeed get into the car, start it, and then drive off without having to explicitly check the headlights since it's now part of the "core" initialization functions. The headlight setting in this case will not prevent the car from driving, but it can lead to a harmful situation if ignored. (In my car, I have to depress the brake pedal in order to initialize (start) the car, so it's an implicit part of the initialization sequence.) Another one is if you're low on fuel. The car won't start if you're out of gas, but if you're merely "low" it will start and run for a while, then die. If you know you need to drive 100 miles, but there's no enough gas to go that far, then you're going to get a run-time exception if you don't increase the fuel level. Not much different than running out of memory after awhile. It's left as an exercise for the driver to check the fuel level directly and add gas when needed. In the 1980's, cars had a "nag" feature built-in that would tell you things like "fasten your seat belt," "check gas level," or "door is ajar". They lasted longer than anybody imagined, but this feature was thoroughly despised by most drivers. This was a "warning" rather than an "error", so the car would drive after being started, but the "nagging" announcements were intended to alert the driver to things they presumably weren't aware of. An "out of gas" state is the only one I can think of when the car won't start (initialize). The transmission setting is distinctly NOT part of the initialization sequence, because it's something that changes the state of the vehicle during normal run-time operations.
  10. The purpose of a class constructor is to initialize the class to a known initial state when it's created. Imagine having to different ways to start your car if you were alone or if you had passengers, just so the system that supports airbags knows whether to only activate the Driver's-side airbag or all of them. Airbag activation based on secondary properties that can't be known until run-time (ie, how many people get into the car) is not part of the object's "initial state". FIRST you start the car. THEN you do other things like activate the airbags. You do NOT want to have different ways of starting the car based on factors that depend upon secondary systems. It doesn't need to be airbags -- it could be A/C vs. Heater; driving in the day vs. at night where lights are required; etc. Creating your objects is like starting the car and getting the engine running. C++ and C# (among others) have a way to inject initial state data into constructors at the time of declaration vs. run-time. Delphi doesn't have that ability, so you need to inject the really core initial parameters in the Create call, and then add others AFTER the object has been initialized via property injection.
  11. David Schwartz

    language updates in 10.4?

    As if that has never happened with anything Microsoft ever published ...
  12. David Schwartz

    language updates in 10.4?

    I don't care about nullables so much as a more efficient way of writing code that tests for a NIL value and stops rather than raising an exception, so you don't need to have if Assigned( xyx ) then all over the place to prevent exceptions. Nullables seem like a back-door way to get support for something that would save quite a bit of time and coding that isn't going to be added to the language just because it's really useful. There are so many idiomatic phrases we use habitually simply because the language never supported ways to avoid them originally; other languages are finally being enhanced to address things like this, but Delphi remains stuck in the Dark Ages when it comes to useful language enhancements. Like the use of strings on case statements that practically every language in use today supports, just not Delphi. Compilers are supposed to make the work of programmers EASIER. I don't subscribe to notions that "we don't do that because it's not in the 'spirit' of Pascal" or whatever. That's just BS. It's like saying you'll never put an electric starter on your cars because it's just not historically accurate with original car designs. So you have to get out and crank a lever in the front of the car to get the engine started. I don't know about anybody else, but I'm sick and tired of hearing off-the-cuff comments from managers and VPs who make technology usage decisions saying that Delphi old and stale so they can't wait to replace their code with "a more modern language". At the place I started working at in mid-January, the CTO cornered me one day after I'd been here about 3 weeks and said, "So how much work do you think it would take to replace all of the Delphi and MySQL with C# and SQL Server?" Why is this such a pervasive and recurring question everywhere I've worked for a decade? There may be something heart-warming about the fact that Delphi can compile code written in 1995, but it's keeping management teams at corporations of all sizes from embracing Delphi because there are plenty of language enhancements in C, C++, C#, Python, Ruby ... you name it, that are not in Delphi, and from all indications will never be. That gives the clear impression that Delphi is old, stale, stodgy, and is something nobody wants to use because it has no support fo the latest language features that other languages have. For 12 years now, I've worked at one place after another where my job was to keep a bunch of legacy Delphi code alive until they can replace it with "something more modern". That's THEIR words, not mine! And I have absolutely no defense for it. They use the Pro version of Delphi, not Ent or Arch, because they don't use any of the other stuff bundled with the bigger packages. Just the language and a few 3rd-party component libs (mostly free stuff). There are other tools that implement Pascal variants that are almost totally compatible with Delphi, and add plenty of new language features that are on-par with contemporary languages. These prove it can be done elegantly and cleanly. But the compiler builders need the motivation to do it. If the folks who own Delphi ever hope to get it mainstream again, they need to bring the language into the 21st century and add features that most other contemporary languages have had for a while now. But when the topic comes up, all we ever hear is crickets. "Oh, but look at all the work we've done with our latest Interbase enhancements!" There's lots and lots of work being done enhancing stuff that hardly anybody uses. But enhancements to the core product are nowhere to be found.
  13. I'm curious if anything has been said about language enhancements in 10.4. I tend to avoid language enhancements, but I'd love to see nullables as well as a ?? and ??= operators, and even a ternary ( x ? y : z ) operator, esp a ternary operator that works with nullables. I've seen that nullables are in the pipeline, but the overviews are getting so high-level that it's nearly impossible to discern any specifics.
  14. David Schwartz

    Why upgrade?

    While I understand and appreciate the arguments some of you are putting forth, in this case we are building apps that are only used in-house. We're similar to a SaaS business where customers post files to an FTP area and they go down a production line and stuff pops out the other end. They don't see what's going on under the hood, nor do they care. We have VMs that are still running WinXP. Most of our code has not been rebuilt since 2011 and it's still functioning perfectly. I honestly don't know why there was discussion about upgrading from Tokyo to Rio since most of the software was built so long ago and there's no need to rebuild it.
  15. David Schwartz

    Why upgrade?

    my predecessor spent a while preparing to migrate from Tokyo to Rio, but left before it was finished. I've been asked how long it will take to finish. My reply was, "I don't see why it's necessary." The only reason they can come up with is, "Because [predecessor] believed it was important and he spent a lot of time preparing for it." I'm not able to find any particular benefit of upgrading since nothing new in Rio gives us anything we need. We're not about to refactor gobs of code just to take advantage of some new syntactical geegaws.