Leaderboard

Hi, I've had lots of enquiries recently about when Bookmarks and Navigator will have a version available for 10.3 - they've been updated and new features added for every release until now. I'm please to say they will be available with the upcoming version of RAD Studio (10.3.1) which is coming out soon. The reason for for being included, and for the lack of news about a 10.3-compatible release in the past month, is that the plugins have been acquired by Embarcadero and so will now ship with the IDE itself. This is great news. I wrote the plugins originally to add features I wanted to the IDE, and hundreds (thousands, actually!) of developers have given great feedback. It's great to know the features will be available to everyone. In addition, due to the pressures of work, I haven't had much time to maintain or extend them recently, and so having them under Embarcadero's wing means they'll live on and be developed as part of Delphi and C++Builder itself. More info in the linked post! - David

I'm here!

I just hope this nice plugins will not be killed slowly by Embarcadero after integration in the IDE like they did with Castalia.

I saw many people using TRTTIContext without freeing it. That's wrong ! The Free function wasn't there for nothing. I just check it and found that it assigns a nil to interface ! procedure TRttiContext.Free; begin FContextToken := nil; end; You should always use Free when a record implements it even if it does nothing !!! It might do nothing currently ... but maybe the developer introduce it to use it later or it does something on other configuration (ARM ?)! As an example, from the Win32 api FlushInstructionCache function does nothing on x86 but it's important on ARM ! My bad ... Sorry. You're missing "@" ! Writeln(' '+lFields.Name + ': '+lFields.GetValue(TypeInfo(@Rec)).AsString); I just played a little with the above code : uses System.SysUtils, System.Rtti, System.TypInfo, System.Generics.Collections; type TRecord1 = record private var FTypeInfo: Pointer; // this must be the first field and all record must implement it. public var FField1: Integer; // Record fields. class function Create: TRecord1; static; end; TRecord2 = record private var FTypeInfo: Pointer; public var FField1: Integer; FField2: string; FField3: Boolean; class function Create: TRecord2; static; end; procedure DoSomething(const Rec); type TRecordHack = record FTypeInfo: Pointer; // since FTypeInfo is the first field in all records, we can hack it ! end; PRecordHack = ^TRecordHack; var PHack: PRecordHack; LTypeInfo: Pointer; LCntx: TRttiContext; LType: TRttiType; LField: TRttiField; LValue: TValue; LKind: TTypeKind; SValue: string; begin PHack := PRecordHack(@Rec); LTypeInfo := PHack^.FTypeInfo; // RTTI: LCntx := TRttiContext.Create(); try LType := LCntx.GetType(LTypeInfo); Writeln(Format('record (%s):', [LType.Name])); for LField in LType.GetFields do begin if (LField.Visibility = mvPrivate) then // skip private (FTypeInfo). Continue; LValue := LField.GetValue(@Rec); LKind := LValue.Kind; case LKind of tkInteger: SValue := IntToStr(LValue.AsInteger); tkString, tkUString: SValue := LValue.AsString; tkEnumeration: SValue := GetEnumName(LValue.TypeInfo, TValueData(LValue).FAsSLong); else SValue := '??'; end; Writeln(Format(' field (%s) = %s', [LField.Name, SValue])); end; finally LCntx.Free(); end; end; { TRecord1 } class function TRecord1.Create: TRecord1; begin Result.FTypeInfo := TypeInfo(TRecord1); end; { TRecord2 } class function TRecord2.Create: TRecord2; begin Result.FTypeInfo := TypeInfo(TRecord2); end; var a: TRecord1; b: TRecord2; begin a := TRecord1.Create(); a.FField1 := 1; DoSomething(a); b := TRecord2.Create(); b.FField1 := -10; b.FField2 := 'foo'; DoSomething(b); Readln; end.

What about that : type TRecord1 = record private var FTypeInfo: Pointer; // this must be the first field and all record must implement it. public var FField1: Integer; // Record fields. class function Create: TRecord1; static; end; TRecord2 = record private var FTypeInfo: Pointer; public var FField1: Integer; FField2: string; class function Create: TRecord2; static; end; procedure DoSomething(const Rec); type TRecordHack = record FTypeInfo: Pointer; // since FTypeInfo is the first field in all records, we can hack it ! end; PRecordHack = ^TRecordHack; var PHack: PRecordHack; TypeInfo: Pointer; LCntx: TRttiContext; LType: TRttiType; begin PHack := PRecordHack(@Rec); TypeInfo := PHack^.FTypeInfo; // RTTI: LCntx := TRttiContext.Create(); try LType := LCntx.GetType(TypeInfo); ShowMessage(LType.Name); finally LCntx.Free(); end; end; procedure TForm1.Button1Click(Sender: TObject); var a: TRecord1; b: TRecord2; begin a := TRecord1.Create(); DoSomething(a); b := TRecord2.Create(); DoSomething(b); end; { TRecord1 } class function TRecord1.Create: TRecord1; begin Result.FTypeInfo := TypeInfo(TRecord1); end; { TRecord2 } class function TRecord2.Create: TRecord2; begin Result.FTypeInfo := TypeInfo(TRecord2); end;

I am not so sure. If I remember correctly, in the very olden days, it was the only option (TP3 or some such -- memories about those days have become a little vague). Short-circuit boolean evaluation came later. Also: https://www.gnu-pascal.de/gpc/and.html: For such cases, GNU Pascal even knows the and then construct, to force short-circuit evaluation.

Ah, indeed. A construct I use quite often. With complete boolean eval that could crash. But you can avoid such problems: if something <> nil then begin if something.someinstanceaccess then ...

or MCVE Minimal, Complete, and Verifiable Example

Make the function a static class function of a record: type TMyPassHandler = record public class function Pass<T:record>(const Value: T): Boolean; static; end; class function TMyPassHandler.Pass<T>(const Value: T): Boolean; begin Result := False; { do whatever is needed } end; Most of the time the compiler should be able to infer the proper type, so a call would look like: TMyPassHandler.Pass(myRec);

We use Mercurial and TortoiseHg. It'sworks very well in Windows environment.

I made my own diff just to get it the way I want it: DirDiff What I didn't want is the stuff that's the same for both twice on screen. The last re-work I did on it enabled diffs between 3 or more files, but that's still not exactly what's needed for conflict resolution. I've open-sourced it here: Github...

You can write it as If ((b and $01) > 0) or ((b and $08) > 0) or ((b and $80) > 0) then ... Or you can create an enumeration and use meaningful names for each bit. type TMyEnum = (mb0, mb1, mb2, mb3, mb4, mb5, mb6, mb7); TMyBits = set of TMyEnum; // = Byte in size function Test: Byte; var mbs: TMyBits; begin mbs := [mb0, mb3, mb7]; Byte(mbs) := $89; // It's equivalent of mbs := [mb0, mb3, mb7]; if mbs * [mb0, mb3, mb7] <> [] then // If one of bit is set ;//... if mbs * [mb0, mb3, mb7] = [mb0, mb3, mb7] then // If all 3 bits are set ;//... if mbs - [mb0, mb3, mb7] = [] then // If no other bits are set ;//... Include(mbs, mb1); // Set 2nd bit mbs := mbs - [mb3, mb7]; // Unset 4th and 8th bit //etc... Result := Byte(mbs); end; It's always better to deal with clearly named typed variables and constants.

Thank you for your feedback. I can confirm that HelpNDoc's download page and setup EXE was cleared by Google yesterday, after our third review request and more than 48 hours blockage. We didn't get any explanation as to what was problematic in the first place and Google's recommended Virus Total web-site didn't even report anything problematic with dozens of anti-viruses. As mentioned by spwolf, this Google decision blocks every users from Chrome AND Firefox (as they are using the same database) from downloading the software and accessing the download page, showing a scary red "malware detected" page instead. It doesn't help the software vendor understanding what is wrong in any ways. Here is how Google (bots!) handled this issue: On the 30th of November 10:09 GMT, we received multiple alerts from Google webmaster console that "Malicious or unwanted software were detected" on our company (ibe-software.com) and software (helpndoc.com) pages. It didn't include any explicit instructions or details about the problem and by browsing through the help pages, it was mentioned that VirusTotal.com was a trusted source for Google bots We confirmed that everything was fine with the download (MD5 + VirusTotal check) and immediately requested for a review 3 hours later, the review failed for helpndoc.com only. This was the exact same message without any additional information. No news from ibe-software.com requests. We made some changes based on user supported Google webmaster forums such as removing redirects to CDN, creating a new release (re-build, re-package, re-sign...) and therefore changing the file name... and requested another review 6 hours later, the review finally came back and was successful for ibe-software.com, which linked to the exact same file. 24 hours later, the review failed again for helpndoc.com yet is was clear for ibe-software.com. Once again, there wasn't any explanation from Google's automated e-mail message We had to wait another 24 hours for the third review on helpndoc.com to succeed and we do not even know why! As we were clueless and it impacted multiple software vendors, we were able to make the following observations. Perhaps this could help other software vendors in case this happens again (fingers crossed): The installer doesn't seem to be the problem: we are using Inno Setup but other reports suggest that other installers were impacted as well (Wise, nullsoft) The code signing certificate doesn't seem to be the problem: we are using a recently renewed Comodo code signing certificate and have came across other applications using Comodo without this problem, and other applications using other certificate issuers with the same problem The programming language COULD be the problem: we are using Delphi 10.1 Berlin and it looks like most applications are written using Delphi. Another impacted software vendor is using C++ Builder Web-site technology such as SSL, redirections... doesn't seem to be the problem: only the download file is marked as malware (and therefore the pages linking to it) while Virus Total confirms that the download is fine Here is the "most official" thread for this problem. Other software vendors are still waiting to get cleared: https://productforums.google.com/forum/#!topic/webmasters/CThwZ6Oq9Ck;context-place=starred I fully understand that false positive happens from time to time and this wouldn't be such as problem if it only impacted some anti-virus software. But it is important to keep in mind that this decision from Google was blocking all users from Chrome and Firefox, which currently represents more than 71% of our trafic! I believe that software vendors should be concerned about this hegemonic Google situation. If you have any contact at Google, it might be worth raising this issue or talk about it to other software vendors to be able to better fight Google bots decisions in the future. Thanks to anyone who tried to help here, on Facebook or the Google thread.

No, and don't expect one soon. There are more urgent issues to be fixed before.