David Schwartz

Not sure where this fits, but we have a dozen servers we connect to via VNC and I’d like to have them all stuffed into one tabbed window like multiple browser tabs, instead of a dozen separate VNC windows. Suggestions?

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.

While I find this interesting, I don't agree with him, although I get where he's coming from. My experience is that most programmers are heavily left-brained and incapable of dealing with things at a more abstract level. I've worked with far too many who simply cannot discuss new ideas without being rooted in concrete examples. There are places that end up hiring folks who are capable of more abstract thinking, and places that don't; I think it's more of a reflection of the people who are doing the interviewing and making hiring decisions. It's like musicians who can play virtually any music like a virtuoso just by reading sheet music, but they can't improvise if their life depended on it. I can make anything sound musical and pretty much improvise everything; I cannot stand reading music. Experienced musicians think I'm a pretty odd duck in that respect. Similarly, I can have very abstract discussions with people, although there are those who can't follow what I'm saying unless I can give them very concrete examples to follow. It can be quite exhausting. I spent several years at a place that had a nice balance. The next place I landed on a project where the core developers were from Bell Labs, and they certainly attracted abstract thinkers, but those who migrated in from other parts of the company were not so much. Another nearby division had a bunch of ex-college professors working there. While you'd think they'd be fairly good architects, my interactions with them left me wondering how they ever got hired. They argued with such ferocious tunnel-vision about microscopic details that it was nearly impossible to get anywhere with them. I've met people who have tried and tried to write components for Delphi but just can't wrap their head around it. Others see very little difference between a unit that's used in a program and turning it into a component.

it would be fun to play with and see what you did, if nothing else. 🙂 I did find something called Terminals, but found it really clunky and glitchy. Not to mention, some of these are on VMs running WinXP in a smaller console window, while some are on the other end of the spectrum with Win10 on an HD-size console. Not sure what can be done about that if they're all running inside a window with the same dimensions for all consoles. Of course, RDP scales to the console size that's needed.

I don't know for certain, but I seem to recall there was a language being floated around the time Anders was stolen from Borland that may have turned into C# a year or so later. MS thought C++ had too much irrelevant stuff in it and not enough things for supporting the evolving technologies they were looking at. They had a couple of people on the C++ standards committee who made several proposals that routinely got shot down. "partial" classes are ideal for supporting auto-generated code. They allow you to spread the contents of a given namespace across multiple files. Personally, I think the whole notion of a "file" as some kind of a meaningful unit of programming has far outlived its useful life. C# has incorporated this in its design, although the programming environment doesn't take much advantage of it. Delphi hasn't even started to move in that direction. The motivation behind this is simple: the IDE should allow us to compose fragments of programs that are saved to a database rather than files, and compose them into larger chunks. Not in contiguous globs of text that we currently call "units" but as little chunks of logic that get glued together as-needed for whatever problem we're solving.

Thanks, but we're using Swagger V2.0. There are C# tools that do this. One thing that makes that really nice is that C# has some constructs that make the classes far smaller than Delphi for the same stuff. Plus, C# supports "partial" class definitions. I don't know why people are so damned allergic to adding stuff like this to the Delphi language. And they want to know why people think Delphi is regarded as "ancient".... sheesh ... it handles a few common use cases really well, and everything else very poorly. That SwagDoc project has the GenerateUnitFileForMVCFramework that I've been playing with. The author did a great job overall separating different parts of the code, but he didn't really separate the Swagger parser from the code generator. (You call the Generate function and it parses the swagger code.) I've been messing with that and discovered they're independent, and it's possible to work with the parser's output for multi-pass code-gen without having to re-parse anything. So perhaps you could use it to upgrade to Swagger V2. Also, I find that although this code appears to be part of an MVC Framework, it's mainly using parts of Teti's DelphiMVCFramework to leverage code for handling Attribute tags on everything. None of the code being generated is specific to MVC per se, as this approach seems to primarily focus on the various Models the API exposes. The V and C parts are left for the user to fill-in. FWIW, it would be far easier to generate C# code from the Swagger data than Delphi code, b/c there's just far less needed for the same goals. That said, there are several different directions one can go with the generated code. The obvious one is a bunch of data classes and a big class that contains methods that implement the API methods. But in looking at our code, I see there are actually two levels of logic: one is a high-level set of methods that take data conforming to the data classes defined in the Swagger spec and pass them to the API methods. The lower-level one is querying the DB and pulling out data and saving it into lists or arrays of data classes from the Swagger spec. Some people here are implementing that lower-level part using an ORM (Entity Framework Core) and some are just doing direct SQL calls. So there's an opportunity to generate more code that would simplify reaching different goals. Just something to think about.

I was recently asked what it might take to move off of a solid, stable Delphi-based platform and replace it with something written in, say, C# and all of the latest wiz-bang frameworks that Microsoft supports. I've seen plenty of such efforts in the past 20+ years, and not a single one of them came in anywhere near time or budget! Yet management remained committed to pouring in exorbitant amounts just to ditch a well-functioning platform written in Delphi. I don't get this. My experience over the past 15 years is that upper management loathes allowing devs to refactor code. "Cleaning up code" is what it's frequently called, and they see it as incredibly risky. While I'd tend to agree if there aren't any unit tests in place, the alternative of totally rewriting the whole thing in another language and platform with a different architecture and set of frameworks isn't my idea of "less risky". Is it just Delphi that people see as somehow incapable of continuing to work? I don't get this bias so many upper managers have against a platform that has been working reliably and relatively bug-free for YEARS.

I've got a newly installed version of Delphi 10.2.3 that throws up a couple dozen javascript errors every 30 minutes (top and bottom of the hour). Anybody know about this or how to fix it? (I haven't seen this on other installations.)

I don't know where it's coming from ... either the Start Page or the Documentation page.

say you have a class like this: TMyClass = class [attr1( 'abc' )] FField1 : string; . . . [attr2( 'abc' )] property Field1 : string read FField1 write FField1; . . . end; Are attr1 and attr2 basically the same? (And yes, I get that they're different attribute classes. That's not what I'm referring to.) What I mean is, does it make a difference whether you put the attribute on the data field (ie, attr1) or on the property (ie, attr2)? Or are they equivalent? So ... is the property Field1 able to see attr1, or attr2, or both?

actually, come to think of it, I guess it's also possible to set attributes on the read and write things, and they can be either fields or methods. I was wondering about the transitivity of the lookup with fields, but with methods it's going to be different. So that pretty much answers it.

What's the difference between these? TMyClass = class of TAnotherClass; TMyClass = TAnotherClass;

I've run into this same problem after installing other libs recently. It's quite a head-scratcher...

I don't agree with that. A good coder can express something in 5 lines what a poor coder takes 25 lines to say. And the poor coder might not be able to make heads or tails of the 5-line version. And six months after writing the 5-line version, the author might not even recognize it! Code you write "now" is ALWAYS "self-explanatory". That's not why one writes comments -- you don't need them in 5 minutes ... you damn well might need them in 5 months, however! I'm going through a bunch of code right now for the first time, and even though the names of things are quite long and the code is well-organized, there are no comments anywhere, and it's really challenging trying to figure out what's going on. Actually, I take that back ... there are some /// comments above some classes and methods in the interface section intended to be used to create some rough documentation. What's missing is any sort of "big picture" explanation other than one method near the bottom that calls 15 different things declared above it, and none of them pass any parameters, yet they seem to be working on several "global" vars (in the class) that are then revised and refined and used among the methods. Well ... some are, some aren't. Being an "expert" sometimes means knowing that "if it ain't broke, don't fix it" applies. Refactoring increases the risk of breaking things that have invisible side-effects. If there are no unit tests, then it's a crap-shoot. I like to put "big picture" comments at the top of units, but I'm frequently criticized for it. They're as much for my benefit as others. I worked at a place once where a colleague would put needless comments like "getter" and "setter" next to the read and write parts of property statements (on 3 lines) and delete comments where I was explaining parameters on procedure and functions. Makes you scratch your head sometimes.

So I've been messing with this stuff all week, and Swagger / OpenAPI seems to be a way of documenting an API, like a DDL for databases. You can build a UI from a Swagger definition fairly easily, but if you need any kind of authentication, it seems problematic. It's ok for basic testing, tho, especially if no auth is needed. Given the derth of "Swagger to ________" code generators, I'm guessing that's not somethign done very frequently. The main one at swagger.io supports a couple dozen languages, but Delphi and Pascal aren't among them. SwagDoc is the only one I've found so far, and there's only one demo for generating client-side code. It's got a few bugs, and there's a lot more it could do. The basic Swagger test UI that can be generated is fairly nice for an auto-generated script. You can read and display data very easily. It would be nice if the Delphi code that's generated had sufficient code generated to produce a similar result, but I guess that's left as an exercise for the reader. Has anybody here ever approached things from this direction -- using Swagger / OpenAPI to help generate Delphi client-side code that makes REST calls? I'm curious what you may have found and problems you encountered. I know Delphi has tools to call JSON-REST APIs fairly easily. But when there are nearly 100 APIs and many of the objects the APIs return have nested objects, lists, and/or arrays embedded in them, that complicates things quite a bit. Or maybe the guys who defined this API have gone a bit overboard? It's a long way from most relatively small API calls and what this particular API I'm working with includes.

hmmmm ... so we have four "variations" of this (maybe more): 1) TMyClass = TAnotherClass; 2) TMyClass = class of TAnotherClass; 3) TMyClass = type TAnotherClass; 4) TMyClass = class( TAnotherClass ); I'm familiar with (1) and (4), but (2) and (3) I've rarely seen used. In what conditions would (2) or (3) be used?

as for me, yes, but that's only handy when I know what I'm looking for. The type filter wouldn't work any differently with or without a deeper hierarchical organization.

Thanks, but I'm just looking for a tabbed interface that collects them into one window instead of a dozen separate windows.

Here are a few random comments about other "code smells".... You seem to be treating classes as records. What's this for? Anything defined as a 'class' is already passed by reference. You don't need pointers for anything related to classes. This ^^^^^^^^ is a very unconventional coding style. First, you're not inheriting this from any base class that has the ability to deal with the attributes ([JsonName(...)], etc), and this one doesn't either. So what are they doing there? As it is, they're little more than comments that are generating needless stuff in your executable. The fields RowName and Modifications should be defined as properties and made 'private'. And there's never any reason I can think of to make constructors or destructors 'published'. Usually they're 'public', and they can be 'protected' if they're in a base class. This is more consistent with typical Delphi usage: TCEItemStatModification = class private FRowName : string; FModifications : TStringList; public constructor Create; destructor Destroy; override; property RowName : string read FRowName write FRowName; property Modifications : TStringList read FModifications; // this is initialized by ctor, never set by the user end; Personally speaking, I'd be inclined to put the RowName as a parameter on the ctor, as well as the list of things that get added to Modifications. They're simply initializers. Why not let the ctor do that? (This would make the RowName property read-only as well, so no 'write' clause is needed.)

Is there any way to add a second level of hierarchy to the tool palette? Like an entry for "Jedi tools" then the various Jedi lists shown there. Or "DevEx" with the various DevEx lists there.

The installer is not the library. FWIW, I installed all 3 Jedi libs recently and have had no problems.

We need a GUI interface to interact with apps that run 24/7 inside of VMs.

the app we're running is Microsoft's mstsc.exe that says it's Remote Desktop Connection. EDIT: Ahh, it looks like the Terminals app you pointed to (that's been moved here: https://github.com/terminals-Origin/Terminals ) is exactly what I'm looking for: The project started from the need of controlling multiple connections simultaneously. It is a complete replacement for the mstsc.exe (Terminal Services) client. I'm thinking I could build a simple tabbed form in Delphi that allows this to be embedded in each tab, or just find an app with a tabbed interface that already does it. I searched Google and didn't find much about embedding apps into Delphi's panels or forms.

it's obviously not finding that BPL. I don't think it has much to do with the Jedi library, if anything. It's complaining about file xyz. Why don't you show that file xyz is really there and that it's findable (via the path), instead of showing that something unrelated still complains when you do something that is trying to access file xyz?

Yes, I use Virtualbox with Win 7. But I haven’t seen this error