Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 07/28/19 in all areas

  1. Uwe Raabe

    Refer to Form Control without using the Form unit?

    That is not breaking cycles, but actually creating them. Cyclic dependencies in the interface simply don't even compile. Therefore cyclic dependencies are only possible in the implementation section.
  2. David Heffernan

    Disaster planning by archiving GetIt installers

    The issue is not what components you use. The issue is the development process. You need to be able to create development environments in a robust way. These environments need to be identical. And you need to be able to build with different versions of your codebase, including different versions of your components. That isn't something that you get with naive package manager use. Yes. That's pretty much the point.
  3. To avoid unit cycles your form units should not depend on a unit which actually translates anything. Them should depend on some interface ITranslator which have methods TranslateProject and TranslateControl. Each unit create the implementation on demand with some kind of factory. E.g. Translator := TFactory.CreateTranslator(); The factory may be implemented as a simple container for implementations. E.g. actual implementation class (which depends on all forms) at some point during initialization registers itself as implementation of ITranslator interface. With this design you don't have unit dependency cycles. In real life case it's better to use some DI container for this instead of creating it by yourself. This is because there is a cycle indeed. You cannot declare mutual units dependency in interface sections. At least one unit should use the other from implementation section. Otherwise the code will not compile.
  4. The recent GetIt failure has exposed some vulnerabilities many of us have in archiving our development machines. Using local backup procedures and virtual machines to archive our development machines is one way we can protect ourselves. But, another reasonable safeguard would be for us to assure that we can build our development environment from scratch, offline. Archiving the RAD Studio ISO is a good first step. But, if the GetIt servers are down, or if older versions of tools become unavailable for any other reason, the ISO is insufficient protection. Perhaps we can archive GetIt installers also? Marco's post (from last year) indicates that the IDE can create an html log of GetIt actions: http://blog.marcocantu.com/blog/2018-july-getit-install-logs.html. Examining the sample logs in his blog, it appears that C:\Users\Public\Documents\Embarcadero\Studio\20.0\CatalogRepository\ might contain the downloaded installers that we could invoke using the command lines that are in the log. I plan to empirically test this approach, but thought I'd ask the expert community here for any insight or experience it has on this. Has anyone here ever tried to manually install GetIt downloads by examining this log and using command lines with the .exe files? Are there any rules about GetIt downloads being self-contained, or perhaps might they also download additional resources.
  5. Design or not, its down 10 days now..
  6. Hi, Lately I've been using a lot more $IFDEF than I use to. And modifying code in the wrong block is what worries me, since there's no difference between active and unactive block. For example: {$IFDEF USE_FEATURE} { .. procedures and functions using a feature } {$else} { .. procedures and functions not using this feature } {$endif} USE_FEATURE might be defined as a project conditional define or in an included unit.( that really depends on the project) Anyway, I would like to know if there is an extension that would use syntax highlight in the {$IFDEF} block when USE_FEATURE is defined, fade the {$ELSE} block, and of course if USE_FEATURE is not defined, the $ELSE block would be colorful and $IFDEF block grayed out. TIA,
  7. David Schwartz

    Best way to check if an internet SMTP server is available?

    This is where it helps to be an old-timer and remember how things worked back in the early days of the internet. The internet was developed by DARPA in the 60s during the Cold War, when the threat of nuclear war lingered in the air and shaped the way people designed things. DARPA wanted to design a large network of independent computers that had no single-point-of-failure in case major cities with central servers got nuked -- literally. Everything was done by dial-up at the time. That is to say, unless you could afford a dedicated phone line, there was no such thing as an "always-on connection" the way we experience things today. And dial-up was slower than molasses in the winter time. I remember 150 baud in the early 70's. Then 300 baud. In 1990, 2400 baud was fast. In the mid-90s, a "high-speed connection" was a dial-up line with a modem that ran at 9600 baud. In effect, virtually 100% of home users experienced what you're trying to argue against as their "normal" use-case. The server (or wherever your emails went next) was NEVER connected. Guaranteed. In fact, the solution for eliminating a single-point-of-failure scenario was to make the entire internet backbone work using store-and-forward mechanisms. They also took this approach because it would be unworkable to have thousands of computers attempting to dial-in to your computer directly just to drop a couple of emails. (In 1988 I did some work for a guy who literally had 25 phone lines coming into his office to support a couple thousand users who'd dial in to connect to his minicomputer that was used to allow search and download county assessor tax records. They charged something like $500/mo per account. He had me write some special driver software that tweaked the 1200 baud modems connected to each of those phone lines.) So servers were set up to collect stuff, then forward it on to the next server closer to the destination, until each email finally made it to an ISP that hosted that email. ONE SIMPLY DID NOT CONNECT DIRECTLY TO THE DESTINATION MTA! EVER!!!! That's just not how things were designed to work. Back in the days of dial-up access, we all remember times when we'd try to connect and the line would be dead. Or someone would be on the phone (or party line). Or it would be busy. Or the number was disconnected. THIS WAS N-O-R-M-A-L. It was also pretty normal to be in the middle of a dial-up session and someone in your home would pick up the phone in another room and the line would drop. So we'd get online late at night when we knew nobody was going to try to make a call. (Generally speaking, nobody called anybody after 10PM.) And THIS is EXACTLY how the internet in general, and mail delivery specifically, was designed to work. You seem to want to be able to assume otherwise. Just build a mail agent designed to work they way MTAs are SUPPOSED to work and save yourself some grief. You can find the actual RFC spec for how SMTP was designed to work here: https://tools.ietf.org/html/rfc5321 If you go back and look at earlier specs, you'll see that not much has changed since the original specs were written in the 60's.
  8. Not that it helps you here, but I try to separate code into separate units, as much as possible. So that I can bind the right routines like here: {$DEFINE ___USE_VERSION1} {$DEFINE _X_USE_VERSION2} {$DEFINE ___USE_VERSION3} uses ... {$IF DEFINED _X_USE_VERSION1} Feature.Version1 {$ELSEIF DEFINED _X_USE_VERSION2} Feature.Version2 {$ELSEIF DEFINED _X_USE_VERSION3} Feature.Version3 {$ENDIF} Which makes matters much more clear and readable. And YES: I also would like to see if I'm in the active part of an IFDEF, good feature. Wouldn't like to see it as comment, but as a kind of comment with slightly different color (maybe darker green), that would be OK for me.
  9. David Schwartz

    Disaster planning by archiving GetIt installers

    I've been unable to make GetIt work since 10.2.1 was released. Some unrelated libs apparently introduced a problem with something that was never fixed, and it raises some kind if stupid error in the interface that prevents it from loading up. Having an automated installer is nice, but we definitely need a way to manually download and install these libraries, otherwise they're pretty much useless. If Embt is going to provide access to these libs for anything more than fun, they need to offer better support. The quality of the libs themselves is great. The interface sucks and Embt doesn't seem to give a rat's ass.
  10. David Schwartz

    Disaster planning by archiving GetIt installers

    I've been using Raize Components since D4 or so. I much prefer them to the regular components. They're rock-solid and exactly what should be provided as the default components, IMHO. I can't build a TON of older projects without it. When Embt bought it from Raize and then priced them at some outrageous amount vs. what we had been paying Raize, I told my account exec, "Sorry, but I'm not upgrading Delphi because without Raize Components I can't use it for my older projects. And I'm not paying what you guys want just to get the libs updated so they'll recompile with each release." One guy wrote back, "We may be making an announcement shortly that will make you happy." Given the slow and steady demise of Delphi in the marketplace, and the general lack of support users have expressed for commercial libs, a lot of otherwise excellent component libraries have been released for hosting on GetIt. If you want a bunch of half-baked crap, visit Torry's. GetIt has stuff in it that Embt has thankfully agreed to maintain so those of us working on older legacy products that use these component libs can continue to use newer versions of Delphi. Without it, I think they'd lose a lot of business. Of course, there's also a ton of demos that only run inside of the IDE, and require you to pay for if you want the full version, which is fine. But it's the presence of formerly commercial libs that I find most valuable. When Delphi went from D6 to D7, a lot of users bailed out and switched to C#/.NET because some popular component libs did not make it through the transition (Dream Components being a biggie). This happened again when Unicode was introduced. If people have to rewrite entire apps because old libs are no longer available with new versions of Delphi, they're more likely to switch platforms than anything else. I think they learned their lesson.
  11. David Schwartz

    Refer to Form Control without using the Form unit?

    I don't know if this will help or not, but you might find it interesting. It's a talk I did for CodeRage 9: http://w5a.com/u/coderage-9-talk
  12. I'm not aware of any extensions with such effect. May be mighty LSP will bring this feature (no). I-Pascal (Pascal support plugin for Intellij IDEA which I develop) does this. Also I think I saw Lazarus does this too but can't find it in 2.0.2. And I agree with @David Hoyle - it's not an easy to implement feature.
  13. timfrost

    Passing back a string from an external program

    To answer your question, yes, I have done exactly this. But in my case program 1 was guaranteed to be a singleton on the machine, so I could just create an empty registry key before invoking program 2 and have program 2 place the result there. If you have control over the number of instances of your program 1 you might be able to adapt this solution. It has the advantages of extreme simplicity and needing no extra tools or special functions.
  14. Having written a few highlights for the IDE for other scripts I know it could in essence be done however the highlighter would need to know more about what it is parsing than just the line of code it currently expects, i.e. what IFDEFs are in play. For those defined in the Project Options not so bad but for those that may be define in code it's more difficult as the highlighter would have to pre-parse the code. This would be a performance issue if not handled in a background thread, i.e. parse some code (assuming the current module only not the project and place a list of active defines in the wizard that the highlighter can use). One other thing would be that the list of colours / fonts the IDE uses is fixed so the colour for the disabled IFDEF section would have to be configurable by the wizard interface. I'll caveat all of the above with - this is just theory
  15. I found out from Dmitry Arefiev. It really should have been included in the release notes.
  16. Arnaud Bouchez

    HMAC_SHA256

    Take a look at https://github.com/synopse/mORMot/blob/master/SynCrypto.pas It is Open Source, works from Delphi 6 up to latest Delphi 10.3, and is the fastest library for Delphi AFAIK - for instance, there is an Intel's SSE4 x64 optimized asm for SHA-256 on x86_64 (Windows and FPC Linux). You can use the THMAC_SHA256 record, or HMAC_SHA256() function for your purpose.
  17. Remy Lebeau

    Generics and Interface

    The DocWiki is correct. Generics are not supported on interface methods. Nor does it make sense to allow that anyway. The main reasons to use interfaces are polymorphism and predictable functionality contracts. If two classes implement the same interface, but they implement the same methods using different parameter/return types, then polymorphism and contracts go out the window. There is no viable use-case where allowing Generics on interface methods makes sense. No. Why do you think you need this? You don't. Find another design.
  18. Unit dependency cycles are bad. Period. One possibility to consider is that of placing all of the units you access into the implementation section. So, for example, if your TranslatorUnit is laid out something like this: unit TranslatorUnit; interface procedure TranslateAll(const ALanguage: TapLanguage); implementation uses Unit1, Unit2; // your list of used units here procedure TranslateAll(const ALanguage: TapLanguage); begin // code here to perform the translation work. end; end. The basic idea is that none of your application units need to be in the interface section. They need to be referenced by the translation routines, but if they are not specified in parameters of interfaced routines, can be declared in the implementation only. I have a module which is built in exactly this way. Although many of the units in the uses clause remain tangled in unit dependency cycles, this new unit participates in -- and contributes to -- zero dependency cycles.
  19. PeterBelow

    Refer to Form Control without using the Form unit?

    You cannot do it this way without using the form units. It is not a good way to translate an application anyway. Have you looked at the IDE Translation Manager?
  20. dummzeuch

    Refer to Form Control without using the Form unit?

    So you want the compiler to check all the references for you without giving it the references to check? Not possible. You could put all the form variables into a global unit, typed as TForm and only use that unit. Unit AllMyForms; Interface Uses Forms; Var TheMainForm: TForm; ASecondaryForm: TForm; Implementation End. Unit TheMainFormUnit; Interface Type TTheMainForm = class (TForm) // stuff here end; // remove the variable declaration here // Var // TheMainForm : TTheMainForm; I'm not sure this would work. It might wreak havoc with the IDE. (Sorry for the source code mess. I'm on mobile and for whatever reason there is no insert source code button.)
×