Leaderboard

I don't mean to sound mean or burst your bublle, but I think you're being set up for failure. You're also talking about a year or two of learning. What you're asking about isn't going to be found in a book. You'll learn it by working on a bunch of different systems and applications over time. If you want to learn OOP/OOD, then take a class -- learn Java or Typescript or C#. This is not the right project to learn it on. Find a project that's already up and running, with the latest (or very recent) version of Delphi, that's on Win 10 or 11, and where there are some others there who can mentor you and answer your questions. The fact that they hired someone who knows nothing about Turbo Pascal or Delphi or anything related to the application, rather than an expert with many years of experience with it, tells me they do not expect a good result in a timely manner. I've been working with Delphi since it was released and can practically write it in my sleep. But the last several jobs I've had all began by being told, "DO NOT TOUCH THE CODE! Just READ it and become familiar with the overall design." They typically expected it to take 3-6 months before they'd let somebody new touch anything, and that's in a situation where there were several experienced Delphi people on the project. Then they'd have me write up something where I had to show them exactly what lines of code I was proposing to change, in what order, and how to test that the changes worked and there were no side-effects. I was every bit as much of a "Delphi expert" as they were, and in some cases, even moreso. Still, it takes a LONG TIME to learn how a non-trivial piece of software is designed, even if you're an expert in the language. If you don't know either the language or the design environment, you're a goner. At my last job, after a month they gave me something that their IT Mgr had "analyzed" and concluded it would take a week AT MOST, to simply "migrate" this one Delphi app from WinXP to Win10. It turns out that the details the IT Mgr had given me were completely BOGUS -- he just looked at some activity going on in the file system for 30 minutes and made up some crap about what he thought was going on. He thought he was watching files being processed and inadvertently deleted. What he was actually watching was a bunch of temp files being created and deleted by a DLL. When he tried it in Win10 and watched it run, it did not behave the same way. Well, DUH! The problem was the DLL was V1.0, released initialy when WinXP was released, it did not run correctly on Win10. To add insult to injury, their license prohibited us from using it the way we were -- which the IT MANAGER should have figured out already, but didn't. That's all I managed to learn in the first week. And some VP had the gall to ask "Did you get it migrated yet? Yes or no?" I wanted to say, "What part of 'the DLL won't run on Windows 10' don't you understand?" Basically, the findings I reported made a bunch of people look like fools, and they weren't happy. But all of this "analysis" was done before I was even hired, and nobody bothered to explain any of it to me first. My point is, you're very likely on a fool's errand here. Your employer could hire experts like me or many of us here and we'd come in, and after studying that app for a week or two basically say, "it's impossible to do what you're asking". YOU don't even know what you don't know -- and THEY KNOW THAT! It might be 6 months of struggling to learn Delphi and all that stuff before you finally come to the same conclusion. You're being set up. My experience migrating old apps like this into the current version of Delphi and Windows is ... it might work ... but more than likely it's going to take some signficant rework and testing to find any parts that depend on obsolete Windows APIs, DLLs, and other libs that may be obsolete and cannot be replaced easily. Meaning that while your desire to learn Delphi and OOP and all that stuff might seem applicable, that's not what's going to keep that app from being easily migrated. Yes, it might compile. Most likely, it won't. And if you don't understand how components and libraries work, or if there are any DLLs or Windows APIs that won't work, you've got a LOT more work ahead of you that's got little if anything to do with Delphi programming. That DLL I mentioned that we couldn't use ... the company refused to sell us the latest version, claiming (rightly so) that their license did not support our use-case. They wanted to sell us access to their own online REST service that they estimated would cost $10k-$15k PER MONTH!! Management looked like someone just stuck a pipe up their butts when they heard that! "Oh, it's just a simple migration" they were told. "It's just a few days of work" they were told. "It won't take much effort at all" they were told. I had to find a replacement for that DLL and ended up finding a library written in Delphi, and it cost under $100. Then my boss had to deal with HIS boss arguing about "spending so much on such a basic library" for a week... I hope you can see that NOTHING I've mentioned here has ANYTHING to do with DELPHI, OOP, or any of the stuff you're asking about. It's just that you don't know that, and your bosses think that's the problem that needs to be solved, just like my managers did before they hired me to work there and assigned ME to do that simple little "migration" from WinXP to Win10. Honestly, I wouldn't touch that project with a 10-foot pole. Been there, done that, and there's no nice outcome. Everybody is going to be looking to shift the blame, and it's all going to land in YOUR LAP. If you're a contractor, I'd bail out of there fast. Somebody well above your pay grade f*cked up and they're looking for someone to blame it on.

I'm sorry, but it seems you answered the question yourself. There simply is no MMX DLL that can be loaded in D2007.

@David Schwartz I appreciate your frank response to the situation I described in my posts. From my discussions with the Project Lead, I don't think there's any malicious intent behind hiring me for this project. His co-lead for the project pushed hard for this project to be funded and commence, and was really interested in reviving this Delphi simulator. My Project Lead is actually looking for more people to come on board the project. I guess it's a situation where I've mischaracterized my skill sets. My Project Lead is aware that I have no Delphi experience and has asked me to take time to become familiar with the environment. I think I'll just have a discussion with him on what his expectations are and to clarify what my skill sets are and be looking for something else to do. If you would be interested in this role, please let me know and we can privately discuss connecting with my Project lead.

Please don't take this personally, but who in the hell hired you for this role? And WHY??? Like the other guy said, this is a task even highly experienced Delphi experts would be nervous taking on. I mean this in the best way possible: turn around and run away as fast as you can from this project!!! You're extremely likely to get fired long before it's finished, and they'll likely come up with some totally off-the-wall reason -- they can't exactly say it's because you're unqualified, because THEY KNEW THAT ALREADY! You may have learned something from it, but you won't be able to use them as a reference, and all you'll be able to say about it was you made some money and hopefully have all of your limbs still intact. I've got a few jobs like this in my past that I don't talk about ... hired for something I knew nothing about, thrown into the fray, didn't know what I was doing, then confronted by an upper-level manager who I'd never met who yelled at me and threatened to fire me, then did. The whole time I was wondering, "What in the heck am I doing here?" I once talked to a guy who left engineering to be a recruiter. He said he did really well at it, in a very simple way: He'd invite a bunch of mid-level managers to a free lunch and ask them if they had any projects that were behind. They'd all raise their hands and he'd ask how many of them had at least ONE they ran that they didn't think would actually finish on-time or on-budget, and they all raised their hands. Then he asked, "who's going to take the fall for that?" They all got really silent and he didn't say anything for a good minute or so. Then he said, "the CONTRACTOR!" He said he had one of the highest closing rates of anybody at the company using that approach. And I had a few jobs come to mind that seemed to fit that perfectly. And a few more over the following years, only at that point I had learned to recognize it. I don't mind being hired as a "fall guy". The annoying part is, nobody wants to tell you, even though it becomes pretty obvious before long. It's not fun. The worst part is, they usually make up some cock-and-bull story that they tell the recruiting firm that makes you persona non grata with them after that. Maybe I'm naive, but I couldn't imagine that the recruiters weren't in on the gig as well. Ask some questions about the history of the project and see if you can figure out why it has taken them so long to do this. There's definitely some politics involved; maybe the person who kept blocking it finally left, or a new manager came aboard and he wants to get this thing killed ... there's something going on there with this project. You're the wrong person for the job, so why did they hire you? (Maybe I'm totally wrong, and it turns out to be the best job of your life and everything works out great! Time will tell.)

It's not my area of expertise, but I'd be sure you won't solve this without a proper browser plugin/extension which may then receive its data from outside. I doubt a simple binary executable from "outside" can reliably do this without breaking with the next browser update.

I'm sure most of us here have spent many hours trying to solve this very problem early on in our Delphi years. There are several ways of solving this. None of them are "right" but they all work. Some seem more elegant that others, but that's always a matter of taste. Frames are nice, but they can be a PITA to work with in the IDE vs. at run-time. (Or they used to be, anyway.) Good luck with it.

This reminds me of "registry cleaners" that do things like automatically remove entries that it determines are paths to files that no longer exist, as if it knows how those would be used if it even did understand how to properly check those things. I actually had this problem with some customers -- they used a snake-oil "registry cleaner" that was removing items my software needed from the registry, causing unexpected behavior. I told the customers that they were using software that was corrupting their system registry under the guise of "cleaning it" and if they needed to use my software, they'd have to stop running bogus "registry cleaners" that indiscriminately removed entries it did not understand. I moved on. I have also dealt with virus scanners and false positives. One of the worst was/is "webroot" that would do more than report false-positives -- it disabled basic Windows functionality for any application it didn't understand, including the Windows clipboard. Hours of diagnosing problems that I should have been able to bill to webroot. In the end, I told the customers, don't use that horribly designed software unless you are willing to whitelist my software. I do understand your problem is competitors whose software doesn't trigger these false-positives. But in the end all you can do is try to make this CrowdStrike's problem by making their customers aware of the issue and complain. After CrowdStrike bricked thousands of PCs across the globe I don't know why anyone would be willing to trust it any more, but I gather most of them are governments or companies fettered by government regulations, and where government bureaucracy exists, sanity and reason flees. Maybe you can write a batch file that obfuscates the string in question post-build. It's not a Delphi bug and should not be treated as a bug in the RTL.

Press [Update Local File Cache] in SDK Manager after libgtk-3-dev installed.

Very nice! Here's some suggestions from looking through the code: The default scope is published so you'll probably want to start your class declaration with private scope: TSizeableLabel = class(TCustomControl) private ... By convention member variables are prefixed with F (for field). private FInSizingHandle: boolean; FResizeInProgress: boolean; FMoveInProgress: boolean; ... The HostedLabel should be a property, with a setter, not a variable (reason comes below): private FHostedLabel: TLabel; procedure SetHostedLabel(Value: TLabel); public property HostedLabel: TLabel read FHostedLabel write SetHostedLabel; ... procedure TSizeableLabel.SetHostedLabel(Value: TLabel); begin if (Value = FHostedLabel) then exit; FHostedLabel := Value; end; When a component links to another component, it should be able to handle that the other component is deleted. You do this by asking to be notified when the other component is deleted. protected procedure Notification(AComponent: TComponent; Operation: TOperation); override; ... procedure TSizeableLabel.Notification(AComponent: TComponent; Operation: TOperation); begin inherited; if (Operation = opRemove) and (AComponent = FHostedLabel) then HostedLabel := nil; end; procedure TSizeableLabel.SetHostedLabel(Value: TLabel); begin if (Value = FHostedLabel) then exit; if (FHostedLabel <> nil) then FHostedLabel.RemoveFreeNotification(Self); FHostedLabel := Value; if (FHostedLabel <> nil) then FHostedLabel.FreeNotification(Self); end; Forget the above 🙂 I commented while I read the code and only now see that the label is owned by TSizeableLabel. In that case, the property should not have a setter. You don't need to initialize your booleans class vars to False. They have already been initialized. You don't need to test for nil before calling Free. Free already does that. You don't need to reference Self unless you need to pass a reference. The scope is Self by default. Use Pascal case: Result, False, etc. Otherwise very clean and readable code. I wish my team mates wrote code that pretty 🙂 Did you consider using 8 small controls for the handles instead? It would have made painting and the mouse and cursor handling much easier, I think.

Out of curiosity, I tried the CrowdStrike analyzer on the PyScripter setup program (signed). Whilst Falcon and MetaDefender gave a clean record, their Falcon Sandbox report gave a threat score 100/100! The report included the following: This report has 268 indicators that were mapped to 106 attack techniques and 11 tactics - Calls an API typically used to query local/system time as file time - Reads configuration files (.ini files) - Marks file for deletion - Contains ability to load/free library (API string) - Contains ability to modify registry key/value (API string) - Contains ability to set file time (API string) etc. Micorsoft's "MicrosoftEdgeWebview2Setup.exe" fails miserably as well. I am not sure any real-world compiled program would pass all these tests. I don't think there is much to worry about here.

That code can be simplified: procedure TForm1.PageControl1Change(Sender: TObject); var sheet : TTabSheet; frame : TFrame2; begin sheet := PageControl1.ActivePage; frame := sheet.Components[0] as TFrame2; StrLines.Assign(frame.Memo.Lines); ListBox1.Items.Assign(frame.Memo.Lines); end;

Turbo Pascal also had an excellent object-oriented GUI framework for DOS called TechnoJock's Turbo Toolkit (later renamed to TechnoJock's Object Toolkit). I was able to build a full DOS GUI for my very first home-made database in a couple of hours. It was truly revolutionary for its time. I also used it to create the user interface for a BBS program I wrote with a friend. Still have all of it up and running on my DOS virtual machine.

Keep it simple - create a class helper for TMemo and add an Assign method and just set the props you need. This will be quicker and easier than messing with RTTI (which can be a bit of a rabbit hole with some property types).

Is there a place where we can find the "official" DUnit source code? It looks like there isn't one. I have DUnit source code here from difference sources - Delphi 10.4.2 Sydney, SourceForge SVN (https://svn.code.sf.net/p/dunit/svn/trunk), Delphi Leak Check (https://github.com/shadow-cs/delphi-leakcheck/tree/master/External/DUnit) and they are all different. It looks like the most "recent" version is the Delphi one. I need to do some modifications to DUnit and I was thinking about creating a GitHub repository to make it "official", applying changes from those sources when needed and accepting changes from contributors. Does anyone has a better idea? Does anyone know if the license allow me to do so (and also apply modifications made by Embarcadero from each Delphi version)?

I wouldn't use any of those solutions. Because that is not golden rule. On the contrary, for reference counted types you would almost always use const to avoid unnecessary reference counting overheard. Problem is not in the method that has const, problem happens at call site. As such it should be handled at call site. First, handling it at call site allows you to trigger reference counting only for references that really need it, next, you will avoid situation where performance will become an issue and someone will go and change method signature according to common practice - using const and will inadvertently break code. Far better solutions than 1. or 2. are using additional variable instead of constructing instance during method call, This is also easy rule to remember - don't create anything inplace. Next solution would be explicitly typecasting TFoo.Create as IFoo And the last one, I like the most because it prevents you to make reference counting mistakes in other code, too, is to have class function that will create instance and return it as interface reference. As for finding all places where you can create possible problem and you need to fix it, simple search and replace can go a long way. For instance - if you have class function New, you can just replace TFoo.Create with TFoo.New and if have same parameter list, you are good.