Bill Meyer

6 hours ago, Lars Fosdal said:

On the topic of unit dependency cycles, I tend to view them as a design weakness.  It is a quick workaround for properly designing with DI and other tools that eliminate unit inter-dependencies. Yet, working with code that has evolved over a long time, they can be hard to eliminate as they are so deeply ingrained.  We have one particular unit that causes a compiler internal error whenever we change something in its interface section and do a compile in the IDE.  At that point only a Build All resolves the problem.

There is little question that they are a design weakness. In fact, that is a gross understatement. The apparent need for such cycles is a clear indicator that some units contain things which should be separated. Often a class has become a Swiss Army knife, providing too much functionality, marginally related. That's bad design, and substantial refactoring may be needed. The same pathology can be introduced, however, in simple procedural modules, where once again, too many loosely related elements are kept together.

Unit dependency cycles:

• are multiplicative, so should be eliminated as early as possible
• exact a penalty in build times, and in one major project, I have seen exponential increase in build times as new modules are added, using the old
• render code analysis difficult, at best
• are often difficult to remove, as they usually require redesign

I have observed that unit dependency cycles are often commonplace in legacy code projects. Further challenges lurk where such tangled modules have been recycled into new projects.

51 minutes ago, Georgge Bakh said:

Honestly, I see no reason why these things should cause slowing down or breaking of code tools.

Code tools must work regardless of code style used.

As to the class constants, I must assume it is a defect in the IDE which is tied to the parser used for code completion.

In my comments, I did not say that the tools do not work; I did identify factors which affect performance. There may well be other strategies which might be applied to avoid the issue with search path, but I consider it poor practice not to name all your own units as members of the project.

Unit dependency cycles are a whole other issue. I can suggest you watch Anders Hejlsberg's video on modern compiler construction. Or just consider with a whiteboard what happens with a small collection of units (A, B, C, D) when:

A uses B, B uses C, C uses A and B uses D, but D uses A and B. It's a mess, and when you consider a larger application, the mess is multiplicative.

If you see no reason for the result, I submit you may have spent little time understanding the process. I have spent a number of years dealing with legacy code in large projects, and untangling things is a challenge.

I've read many complaints about speed and stability of the IDE. And I have made many such complaints. But in fairness, I have seen in large legacy projects that there are many things we can do which undercut the performance of the IDE. For example:

1. Leaving units out of the DPR, relying on the search path. Slows code completion.
2. Declaring const field members in a class. (D2007) Breaks code navigation below that point.
3. Accumulating unit dependency cycles. Slows IDE response, but also slows the compiler on full builds.

There are other "thoughtless coding tricks" which may also contribute to poor behaviors, but those three are big.

Also, how many third-party components have you installed? Are they all solid and stable? That has been a risk area since D1.

On 6/24/2019 at 8:23 AM, Daniel said:

Interesting. I'll look into this.

On  further experimentation, I see that the behavior is specific to Firefox, and does not happen on Chrome. Perhaps is it an effect of privacy settings?

I have updated my settings to disable notifications, yet I keep getting the dialog where I am invited to accept notifications, whenever I come to the site. It becomes annoying.

On 6/13/2019 at 12:16 PM, David Heffernan said:

Python documentation is excellent. Likewise C# documentation. And so on. Delphi is an outlier here. 

I've no doubt Delphi is an outlier. The powers that be clearly failed to recognize that the books in the box represented a significant fraction of the value of the product.

Also, there are numerous products for which "documentation" means simply a reference manual, and though such is essential, manuals discussing usage and library application are also important. Delphi once had an array of volumes, and they made it much easier for newcomers to the language to be productive quickly.

16 minutes ago, Lars Fosdal said:

I wish the various Json classes were better documented.  http://docwiki.embarcadero.com/Libraries/Rio/en/REST.JsonReflect is particularly poorly documented with regards to marshalling, interceptors and converters.

I have long been wondering if the TJson.JsonToObject<T>(aJsonString) can be made to handle mixed type arrays {"list": [5, "text", {"prop": "value"}]} by injecting converters, but it seems impossible - but then again - the above mentioned tools are undocumented.

To remember when things were documented is to be old.

15 minutes ago, Joseph MItzen said:

Embarcadero can't fire him; Idera purchased EMBT and he was the person Idera picked to oversee Delphi. I'm not sure this was his idea either. I heard it was Michael Swindell who came up with the Delphi Pro EULA change (as well as the bogus 3 million users figure) and he's not only still there, he's listed as "Senior Vice President of Marketing and Product Management".  Let's not rule him out as a suspect.

Also keep in mind that they've told us for 20 years now that we don't understand marketing. Perhaps not -- I certainly do not understand THEIR marketing. But in my career I have learned a good deal about customer retention.

According to LinkedIn, his title is now: Mergers and Acquisitions Executive Advisor at Embarcadero Technologies.

And that does not seem to be marketing.

52 minutes ago, PeterBelow said:

Keep in mind that the IDE uses a different desktop while in debug mode. Move the IDE back to the other monitor and then save the desktop and make it the default debug desktop, that should fix the problem.

Smacked myself on the forehead over that. Thanks.

Installed Delphi 10.3.1 Starter Edition the other day on my personal machine. Although the experience so far is generally positive, I note that with the IDE on my screen 2, when I run my app, the IDE moves to screen 1, and the app opens there, as well. Thoroughly unpleasant behavior, and quite unexpected after so many years of multi-screen operation in Windows. I see RSP-12271 and RSP-12956. The earlier case is now nearly 4 years old. One might think such a behavior would get quick attention.

10 hours ago, Berocoder said:

I just wonder why not people using VmWare or similar virtualisation for Delphi? Then you never have to move to a new computer and this problem is gone. A VM have also other advantages.

Many do use VMs. Many did not in the days of D5..7.

2 hours ago, Joseph MItzen said:

It's a horrible, horrible outfit that's little more than a self-publishing firm that takes a large percentage of your sales and does nothing in return.

As with most generalizations, there is probably some truth in your comments.

That said, the relatively small number of books I have acquired from Packt have been better than average. In particular, they have done a very nice job with e-books, which for code, are notoriously difficult to format well.

Very few publishers will consider a Delphi title any more, so self-published books and books from Packt or perhaps Manning are among the few available resources. Packt also publishes some very capable authors, and I certainly number @Primož Gabrijelčič among them.

Self-publishing is not a valid condemnation, either. Our own @Dalija Prasnikar published a very worthwhile volume on memory management in Delphi. (Full disclosure: I did assist with proofreading and editing on her book.) Equally, some self-published books on Delphi have been pretty disappointing.

Software development books appear most often for well marketed language tools, whether they are expensive or free. One metric I have watched is price per page. When that goes higher than five to eight cents, the book better be excellent. Sadly, that is not often the case.

Maybe. But I thought I remembered having been able to "buy" a free special at the $0.00 price in the past.

10 minutes ago, Daniel said:

😉 I am feeling a little stupid here. But how can I download this book? There is an option to *buy* the E-Book for 9,99 USD. Maybe this would be the way to go for a download?

Do you have an account registered? That may be the key to getting the free download. I've found the site a little confusing, but once you have a title, you have it registered under your login, and can access it repeatedly.

9 hours ago, Der schöne Günther said:

I still don't get quite behind that language server thing.

Worth watching for insights into the value of a language server:

3 hours ago, Uwe Raabe said:

I am not sure they would get away with that - at least here in Germany. As long as the customer actually paid for the perpetual license (this excludes the CE), the ability to use it legally cannot be prohibited just because there is no current support contract. At least a reasonable fee for the registration bump would perhaps be acceptable, but definitely not denying it completely.

The history of stupid licensing conditions in the USA is as old as shrink-wrapped EULAs. The one ray of hope was the original Borland "just like a book" policy. 

2 minutes ago, dummzeuch said:

That's one reason I have switched "my" license to using a license server. No problem with having to increase the registration count any more.

Had an unpleasant experience with the license server last year, which necessitated a new slip file. Although the license shows perpetual, there is a subscription expiration date in the license, and that seemed to be an impediment if it became necessary to install new, as in creating a new VM.

Also, the license server "solution" requires that Delphi be able to reach the server at least every 30 days.

Wow. Masterful marketing. This will make it easy for any who have considered dropping off to do so.

For years, we have  been assured that developers simply don't understand marketing. That may be true, but clearly we are not alone in that deficiency.

On 5/17/2019 at 9:11 AM, Rollo62 said:

So how to solve this paradox of the most valuable company in the world ?

"Most highly valued" is not equivalent to "most valuable."

16 minutes ago, Mike Torrettinni said:

You have a point there, but I'm a sole developer on this project, so I don't have this problem.

Coming into a project which has built for years on the philosophy that a "sole developer" could deal with things, and then success led to 10 or more developers, I have to say I think it is best to plan for success. Legacy code is too often very ugly.

On 5/4/2019 at 12:23 AM, Andrea Raimondi said:

Use RAPWare and all your nightmares will be laid to rest. 

Not an option for me at this time. The current solution seems to work correctly, but with an attachment, and where Outlook is the default client and gmail the recipient address, there is a second, phantom attachment. It proves to be 32K of memory image. Where the default client is Thunderbird, or where the destination is not gmail, we do not see the phantom attachment. Also, the phantom does not exist unless we pass a recipient address in the call to send MAPI; if we pass only the attachment name(s), then no secondary is created.

3 minutes ago, Fritzew said:

Hey, they need to earn money somewhere? Do you work for nothing?

Linux is free, not Delphi. If people want to pay for Delphi to build software for Linux, let 'em. So long as Delphi Pro is not free, I don't see that it is "work for nothing".

16 hours ago, David Heffernan said:

David is making a good point here. If Emba were starting from scratch here, would they end up with all these different incompatible procedural types? I doubt it. 

Agreed. However, they are not starting over, and would be unlikely to do so, with the low popularity of Pascal today. Given the inertia in the existing code, and concerns over breaking changes, as well as the lack of deeply committed language heavyweights on development, I think that the trend to cross-platform is likely to continue to dominate.

I would like to be proved wrong on that.

After all these years, I would have thought this should be simple, but apparently not. My app needs to be able to send mail via the installed default client. The assumption is that MAPI will be used, but if that is an issue, I suppose it could be changed. 

My problem is that on systems with Outlook, I have not been successful. If I install Thunderbird, and set it to be the app for mapimail, it works fine. But obviously, I need to be able to send where Outlook is the client. I have been reading Microsoft docs, and checking registry keys, and still have not found a clear answer to why some systems work and others do not. That said, I have never been a specialist in this area, so my own ignorance of the mechanisms is an impediment. I would appreciate it if anyone can offer a simple and reliable solution.

26 minutes ago, David Schwartz said:

<snip>

 

And here you are redoubling your efforts to explain to me in ridiculous detail why the simple thing I want to see possible at the source code level is impossible to do.

Pesky facts. You cannot do what you wish, with the product which exists today.

26 minutes ago, David Schwartz said:

<snip>

I'm really not interested in the technical reasons why this suggestion isn't possible today. Just like I'm not interested in justifications why you can't use strings in case statements in Delphi while most other languages today allow it. There has to be a willingness on the part of the vendor to add these sorts of upgrades to the language instead of defending their absence, which is the normal case with Delphi.

Facts don't yield to attitudes. Hard to say what the future holds, but so long as the pursuit of cross-platform seems to take a high priority, the enhancement of currently functional language elements is unlikely to be reconsidered, IMHO.

You asked how to do what you want, and the answer is that you can't. At least not now. We all have our pet wishes for Delphi features, and I think there could be astonishment at how little commonality of opinion there is.