Bill Meyer

2 hours ago, Anders Melander said:

As for MVVM I'm not convinced Delphi should do it at all. Not every pattern fits every language.

Particularly since MVVM appears to have been created largely to fit the specifics of C# and XAML.

1 hour ago, David Heffernan said:

The point of the book is that adding programmers won't necessarily result in a better output.

Oversimplified, but Brooks demonstrates that adding programmers to a late project makes it later, and shows why that is inevitable.

1 hour ago, Sherlock said:

I didn't read the book, but I'm guessing that only applies when you add those programmers to the same problem. Luckily Delphi has a ton of problems, that could each feed a programmer for at least a month

Make time to read it. Your guess is correct, if the "problem" is defined broadly, for example, the compiler, the code editor, and so on. Thinking that smaller chunks may be attacked in parallel is risky, unless you have a very clean architecture and minimal coupling. And tasks defined and assigned by a product architect.

In Delphi XE, I see that the Ctrl+Alt+M shortcut is assigned to the View Debug Modules menu item. I used GExperts to remove that shortcut, as I do not much use it, and it conflicts with the MMX Add Method shortcut. I now see in GExports that there is no conflict on Ctrl+Alt+M, and that the shortcut is still assigned to MMXAddMethodAction. Unfortunately, the MMX command still does not work. Tried restating Delphi, and it did not help. Have I missed something, or is this not functional in XE?

I have questions regarding SynEdit-2.

What is the earliest supported version of Delphi?

What are the dependencies on other packages?

I ask because I have tried two versions of Delphi, the latest being 10.2.3, and neither one will build the runtime.

44 minutes ago, David Schwartz said:

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.

Context frames pragmatism. Mil-spec is a notoriously unreliable category. Many years ago, I was regaled with stories from former employees of a major semiconductor manufacturer of shipping dates met with chips which didn't even have the right number of pins.

On the other hand, I contend that the simple PC power supply is one of the most reliable devices on the planet. I can't recall the last time I had one fail.

Some of the assertions in this thread display a serious lack of real thought. Choose the wrong device, and you can't compete on price. And if the customer is more sensitive to price than to the occasional failure, that is a critical error to make.

There is a very famous tale of the time the master computer on the space shuttle disagreed with the results from the four lesser devices which checked its work. They decided to believe the master, on the premise that because of its stunning cost, it was more likely to have been well programmed and well debugged. The four lesser (6502-based) devices were correct.

12 minutes ago, Remy Lebeau said:

In D2007, there is no Offset parameter in Pos(), only in PosEx().  Here are the declarations from D2007:

You are correct, of course. I think I copied that from help, though. Should have checked more closely.

On 6/28/2020 at 8:33 AM, dummzeuch said:

Recent IDEs are supposed to use up to 3 GB and since the language server is a stand alone executable it might use another up to 3 GB. And 6 GB might be sufficient but definitely is not plenty to run Windows 10 + the Delphi IDE, especially if you also want to run/debug your own executables.

I routinely operate in VMs, and my largest are given 6GB. I have one such with Tokyo in which I build an app where Delphi reports nearly 5 million lines of code.

12 hours ago, Angus Robertson said:

PosEx was available in Delphi 2007, but became obsolete in XE3 when Pos got a third offset argument. 

 

function Pos(const SubStr, Str: UnicodeString; Offset: Integer = 1): Integer;

In D2007, I have the Offset argument.

Can't tell you when it was added, but it is present in D2007.

32 minutes ago, Stefan Glienke said:

I think you meant to write:

TItems = TArray<TItem>;

Apart from not having to type the angle brackets anymore this is exactly the same type as TItems is just an alias for TArray<TItem>

Does using a defined type play any part in reducing the bloat of generics?

31 minutes ago, Stefan Glienke said:

Those languages to my knowledge don't also have something like the initialization part of a unit which might cause a chicken-egg-problem.

In my experience, the initialization section is dangerous. When you have a large legacy project with many unit dependency cycles, and begin working to clean up that issue, the changes in uses clauses may lead to reordering of the initialization sequence. I found it necessary to log the existing order, then replace initialization sections with InitializeUnit procedures called from an initialization manager. That let me proceed with the cleanup. Without that change, I soon had an app with a lower dependency cycle count, but which did not work.

2 minutes ago, Attila Kovacs said:

@Uwe Raabe I see, I don't have this panel on the left, I'll just roll my own to work with selection. Thx anyway.

You can open the MMX Code Explorer, and drag/drop to Object Inspector area.

17 hours ago, JRodenhi said:

I just this morning dealt with the same issue.  The package I was attempting to install was a design time package: dclDragDropDR103R.bpl.  The problem I had was that the design time package required the run time package, a common requirement, and when the run time package was compiled, for some reason, it was not written to $(BDSCOMMONDIR)\bpl.  I manually copied it there and the design time package installed just fine.  I have not figured out why it was not written there to start with, but this fix will work for me for now.

I had found this advice on stackoverflow:

copy "$(OUTPUTDIR)\$(OUTPUTFILENAME)" "$(BDSCOMMONDIR)\Bpl"

I tried it, but again got the same error. I also tried without that, and adding my BPL location to the PATH, as another thread suggested. That also failed.

I need to install in Tokyo a set of components from an older release which I can use while waiting for the corporate purchasing wheels to grind on a new license.

I am able to build both the runtime and design time packages with no errors. But when I try to install, I get this:
Can't load package s:\Inst\Comps\ThisPackage.bpl.
The specified module could not be found.

The module is present, at the path specified in the error. I am at a loss to know what might be the cause of the problem. I have verified that the dcp files of the units in the requires list are all present.

Any clues would be welcome.

29 minutes ago, Lars Fosdal said:

Discovery = DFS

Processing = BFS on Discovery -> Parallel worker threads processing queue?

 

The efficiency depends on a part of Windows file share architecture that I have never dived deeply into.

Coming from a single remote computer, will multiple concurrent file accesses be truly parallel, multiplexed or serialized?

There is also the question of disk thrashing defeating the parallel approach. You can get a hint of this in BeyondCompare, if you set up multiple large copy operations, and run them in parallel.

13 minutes ago, Attila Kovacs said:

Doesn't this network license cost you mobility? What about notebooks, travelling, home office, etc..? Do you carry a shadow VM with your notebook which runs in the background?

The net license needs to reach the server at least every 30 days, so you are not on a very short leash. On the other hand, if the doors closed, you could be toast in 30 days.

40 minutes ago, David Schwartz said:

The problem isn't the compiler -- it's the 3rd-party components like Dream Components that died on the vine and couldn't easily move forward.

 

If they want to fix the problem, Embt should consider buying the rights to these old component libs and investing their own resources in making them work on the latest versions of Delphi. Add them to GetIt and give people a legitimate upgrade path. Whoa! What a novel idea! Still, a lot of folks still won't consider upgrading because it's harder than ever to find developers with solid Delphi skills today.

The old components are A problem, and certainly can be significant. I've dealt with this in the past, and am doing so now. And it is not only that old components are an issue, but that it is common to find in legacy projects large numbers of components, because there was a natural tendency to want to try the latest shiniest toys. This wide range of components to be replaced increases the technical debt to be paid. And yet, I would not want Embarcadero to expend monies and development resources bringing these into compatibility with current compilers. (And which current compilers, come to that?)

43 minutes ago, David Schwartz said:

Another option is to have a separate maintenance program for legacy products. I have not found a single job in the past decade doing NEW Delphi work -- it's all supporting LEGACY apps that were written in the D4-D7 years. Maybe they're using newer versions of the compiler, but it seems silly to me that the company is COMPLAINING about the fact that all of these old legacy clients are refusing to pay their ridiculous maintenance fees to stay exactly where they are. It's nice that Embt wants people to move forward, but until more jobs start showing up for NEW DELPHI PROJECTS, they're doing little more than Sisyphus pushing a rock up a hill while complaining about the effort involved.

This I would doubt to be practical. Look at the current license fees. Those seem insufficient to pay for the extent of improvements we would all like to see, but you would divide these resources to apply some portion to legacy issues? That will clearly work against the rapid advancement of the product.

47 minutes ago, David Schwartz said:

The world is moving to Open Source Software. Delphi is one if the few remaining products that's not just NOT OSS, but VERY EXPENSIVE for commercial use.  Microsoft subsidizes the crap out of their dev tools, as do others like IBM and Oracle. I think the best thing for Delphi would be for Embt to push to get Delphi acquired by a company that can afford to move it in the direction of OSS by subsidizing it from other product revenues. Instead, they keep raising the costs to customers who are mostly using it to MAINTAIN OLD CODE.

OSS is such an interesting swamp. For Embarcadero, the obvious problem is revenue, which the rising license fees suggest is less than they wish it to be. I fear that part of the problem is that they (like politicians) fail to adequately consider that the relation between fees and revenues is elastic. Doubling the fee will not double the revenue, as it will drive some not to renew. Basic economics. But will any company wish to buy Delphi to take it to OSS? The world perceives that Delphi is dying. They need not be right, as perception drives action. Idera, having spent a good deal (we assume) to acquire Embarcadero, will want a good deal for it. That suggest the need for an OSS company with deep pockets. How many such exist? And as they are almost universally committed to C and C++, where would be their motivation? Acquisition of a market of uncertain size for a product which many choose not to renew annually? Further, OSS is itself no guarantee of future success.

50 minutes ago, David Schwartz said:

This is a MARKETING PROBLEM for Embt. I don't think they have any right to complain when they have steadfastly maintained a posture that has gotten them exactly nowhere in the market. There's no evidence that their products are being used for more NEW product development than to support LEGACY projects. Where's the beef? Or rather, Where's the NEW work?

In case you missed it, the consistent mantra has for years been that we (the market) are clueless about marketing. And about the relative merit of improvements, enhancements, and repairs. And that is an inescapable part of how we came to be where we are now.

I can envision many changes which I think would be beneficial for the future of Delphi, but as none of us is in possession of any meaningful data regarding market, revenues, and so on, it is purely speculative.

And to be very clear... anyone who thinks that letting me install my old D7 will have ANY impact on sales of more recent licenses is clearly ignorant of the product, as well as the market.

11 hours ago, miab said:

Why can't I open tables with lowercase names?

For example: Customers

Why not ask the publisher? info@texteditor.pro  I have found him responsive.

On 5/24/2020 at 11:59 AM, Uwe Raabe said:

Not sure how you do, but I have always just copy the Delphi 7 license data to another machine without any further registration. Actually I guess that Delphi 7 is not even covered by the ELC server - it is just way too old. At least you should still have the original CD, so no need to download.

I have no issue with a limit on the time in which versions could be downloaded, but prior to the recent bump to installation counts, I learned the hard way that my venerable copy of D7 could not be installed as licensed, despite my having the installables and the license code. And I am sorry, but that's a bad policy.

Back in the day, I used to license new releases whether I needed them or not, just to support a company I valued. Now we are asked to pay impressive license fees, and if we do not stay current, we lose the ability to reinstall old versions, which may occasionally be needed for one reason or another. And curiously, the mantra has been that developers don't understand marketing. Sorry, but that dog won't hunt. Any of us who have made our living through contract work or custom development certainly have hard earned knowledge of marketing. And as to marketing, any recent promotion of Delphi apart from embarcadero.com?

45 minutes ago, Dalija Prasnikar said:

You are right about permission part.

The rest is a guess based on historic practice. Makes me just as right or wrong as any other speculator. 😉

1 hour ago, Rollo62 said:

I hope this is ending the long, long favorized age of "SORRY, I can't say anything, because of RadStudio Beta NDA will kill me and eat my soul".

I think you will find that it is not a change in policy, but that they have been given permission to write about the coming release, which is likely to appear rather soon.

I have had success with ProDelphi, which has been well maintained. My only complaint is that as it will instrument a maximum of 64,000 routines, on large projects, you must enter a list of folders or files to exclude. That said, I have been very pleased with it over the years. There are 32 and 64 bit versions for Delphi and for Lazarus, and the price is low. http://www.prodelphi.de/

4 hours ago, Lars Fosdal said:

Wow! That fact had eluded me!

Yeah, it's in the fine print. 😉 I learned that one only in the last few years.

My colleagues tell me they have identified a problem in the copy of superobject which we use in D2007. The problem is not present in the version we use in XE7, but I am not aware of what may be different, and no one appears to have noted when and where the two versions were acquired.

I am also told that there have been a great many forks of superobject, which makes it all more confusing.

What version do people here use, and what is considered the gold standard now, if there is one?