aehimself

I inherit most of my classes from TObject (I have a habit of freeing what I create myself) and ALL of them have inherited calls in constructors and destructors, even if the Create was ReIntroduce-d. There are a MINIMAL amount of cases when this was strictly forbidden - there I did the same what @Dalija Prasnikar did - put it there, comment it out, put a comment why it is commented out. With links, if possible. These just feel empty without inherited calls, even though I know they do nothing. On the other hand, my OCD makes me capitalize almost every instruction (Create, If, Then, Begin, End, Procedure, Function, etc.) so it might be just plain stupid after all 🙂

@Fr0sT.Brutal Call me old-fashioned, I'd simply use {$REGION}-s 🙂 Nevertheless yes, this is a valid case. Thanks!

Ah, so those are the C header files...?! Basically only the descriptors? Tbh I still don't get why splitting Interface and Implementation would help to avoid code duplication. If you have two units where the implementation section is the same, you can use helpers / a class which does the work / not to have two different units but use only the first one. Take this with a grain of salt, though. I just can not - yet - imagine a scenario where this would be beneficial.

There is nothing fanciful here. There is only a substantial difference between "I have a feeling" and "I know for sure".

Were there any changes to TZipFile alltogether? I'd love to see native LZMA support and the ability to open some "corrupted" ZIP files too (like what 7Zip does). I have a file which was compressed by a C# code. Delphi either throws a "Invalid central header signature" exception, or manages to open the archive but sees no files in it.

I read here on DelphiPraxis that the correct way to get a stack trace for anything is just to extract the stack addresses and translate those back to function names on the developers machine. I could achieve this with the suggestion here and with a custom .map file parser I can get the function names back but unfortunately there's too much trash. I also don't really understand this area, my parser was built by trial-and-error... better to let the experts handle this kind of thing. I know I could alter how DebugEngine actually displays the stack trace but it still needs a .map file (right next to the .exe or integrated as .smap) which is not just making it easier to attack the executable but easily adds ~40% to the size. I guess the question is... does DebugEngine support this already and if no would it be complicated to implement it?

I'm using this code called from various places (e.g. WM_SIZE): Procedure TDBGrid.UpdateScrollBar; Var dataset: TZAbstractRODataSet; si: TScrollInfo; Begin dataset := Self.DataSource.DaaSet; If Assigned(dataset) Then Begin If Not dataset.Active Or (dataset.RecordCount <= Self.RowCount - 1) Then ShowScrollBar(Self.Handle, SB_VERT, False) Else Begin ShowScrollBar(Self.Handle, SB_VERT, True); If Win32MajorVersion >= 6 Then SetWindowPos(Self.Handle, 0, 0, 0, 0, 0, SWP_NOSIZE Or SWP_NOMOVE Or SWP_NOZORDER Or SWP_NOACTIVATE Or SWP_NOOWNERZORDER Or SWP_NOSENDCHANGING Or SWP_FRAMECHANGED); si.cbSize := sizeof(si); si.nMin := 1; si.nMax := dataset.RecordCount; si.nPos := dataset.RecNo; si.fMask := SIF_POS Or SIF_RANGE; SetScrollInfo(Self.Handle, SB_VERT, si, True); End; End Else ShowScrollBar(Self.Handle, SB_VERT, False); End; This should show the position correctly. To make it actually scroll the dataset, do Procedure TDBGrid.WMHScroll(Var Msg: TWMVScroll); Var dataset: TZAbstractRODataSet; si: TScrollInfo; Begin If (Msg.ScrollCode = SB_THUMBTRACK) Or (Msg.ScrollCode = SB_THUMBPOSITION) Then Begin dataset := Self.DataSource.DataSet; If Assigned(dataset) Then Begin si.cbSize := SizeOf(si); si.fMask := SIF_ALL; If Not GetScrollInfo(Self.Handle, SB_VERT, si) Then RaiseLastOSError; dataset.MoveBy(si.nTrackPos - dataset.RecNo); Msg.Result := 0; End Else inherited; End Else inherited; End; I think these two were necessary. If it doesn't work let me know and I'll check what else I added which changes this behavior. Edit: Misread the question, this still won't scroll while you are dragging. I'll leave the code here anyway - it might be useful for some. Edit-Edit: Extended my code with the suggestion of @Uwe Raabe, now it does update properly while the scrollbar is being dragged. Thank you!

I don't know what causes this, but sometimes (even within the same project) this header menu item won't show correctly - neither of the draw methods are called. By experimenting I found out that turning OwnerDraw on on the popup menu itself fixes it on those affected. Anyone has any ideas? How come some menus work correctly without and some required OwnerDraw to call the menu items drawing methods? Edit: Also, assigning an imagelist fixes this, even if no menu items are using any image whatsoever.

What about Server 2003? Also, most built-in machines are still on XP (older ones can be even on 2k). What I loved about Delphi until now is that if you write the code thoughtfully it runs on Win2k up. And while I can understand the business decision behind this it still hurts a little 🙂

Sorry for my previous post being so blunt - I just had different matters to attend to and wanted to leave my comments. With the reappearance the issue is that if the user leaves his PC for half an hour, 30 dialogs will be shown as not even a modal window "blocks" processing further WM_TIMER messages. In these cases I'm usually wrapping the whole OnTimer event in a Timer.Enabled := False; Try [...] Finally Timer.Enabled := True; End; to make sure I'm not rendering my app in an unwanted state. As for the error handling even if this functionality is being used once in a lifetime it worths to add those extra 2-3 lines. Anything is more beautiful than the standard application error dialog 🙂 Just my 2 cents.

This code is completely missing error handling and does not consider access sharing and will read only the first line of the message. As an extra if the file is not deleted it will pop back up every 60 seconds. If {$I-}, use ERRORLEVEL to determine if the Reset was successful, if {$I+} swallow (or just politely indicate) the error. Wrap the Reset...ReadLn...Close to a Try-Finally bloc to ensure the file will be closed no matter what. As for access sharing you might want to use TFileStream instead with fmShareDenyNone.

@David Duffy I have no XE experience (went to 10.0-10.1 from 7) but you can fall back to the idea of @Lars Fosdal safely: TStyleManager is only used here to extract colors of the currently active style so the header will always "fit in" nicely.

Seriously, wtf...

Does anyone know what is the name of Delphi's menueditor? I only could find it in FMX but I guess I should be looking at the VCL version. It would be nice to extend it so it is capable of adding header items.

Hello, We had a large legacy component suite which I managed to split into Runtime and Design time packages in preparation to be able to build our application in 64 bit. I don't have much experience, so what I did was, basically: - Created a new package, set it as runtime only, moved all contains and requires section from the old suite - Created a new package, set it as design time only - Attempt to compile the runtime package - Move units to the design time package which blocks compilation (has references to designide, etc) - Repeat until both packages compiled error free - Added "implicitly imported" units to design time package All works fine, except one strange issue. Delphi chooses a seemingly random unit and throws an Internal Error when I want to install the package (compiling works fine both in 32 bit Debug / Release). Here's the twist: if I close Delphi, modify the unit with VS code and add a line break to the end of the unit (or remove one - basically change something completely insignificant) and save, reopen and install - all works just fine. I'm wondering if I missed something when creating the packages? Did anyone face this before? Does anyone has any tips I can check? Thank you!

It seems so far that I solved the issue, the Internal Errors are gone - at least I can not reproduce them no matter how hard I abuse switching branches (where the component suite is the old) or building-installing. What I ended up doing was to have a runtime package, a design time package for component installation in the IDE and one more design time package for the property editors. This didn't work until I realized I set the required package of the property editors to the runtime package. In the moment I changed this so the property editors "only" require the first design time package, all started to work. During the trial process I also trashed several old units which function is now covered by Delphi itself and corrected some programming issues too but the error itself went away by changing the required package. I don't know what caused the issue at the first place (and more importantly why it went away...?) but this can be a possible solution too.

I ended up combining the code of @chkaufmann and @Lars Fosdal plus added the always-disabled property. The end result fully supports VCL styles and looks awesome! The full code became: Unit uHeaderMenuItem; Interface Uses Vcl.Menus, Vcl.Graphics, WinApi.Windows, System.Classes; Type THeaderMenuItem = Class(TMenuItem) strict private Procedure SetEnabled(Const inEnabled: Boolean); Function GetEnabled: Boolean; protected Procedure AdvancedDrawItem(ACanvas: TCanvas; ARect: TRect; State: TOwnerDrawState; TopLevel: Boolean); Override; Procedure DoAdvancedDrawItem(Sender: TObject; ACanvas: TCanvas; ARect: TRect; State: TOwnerDrawState); Procedure Loaded; Override; Public Constructor Create(AOwner: TComponent); Override; published Property Enabled: Boolean Read GetEnabled Write SetEnabled; End; Implementation Uses Vcl.Themes, System.SysUtils; Procedure THeaderMenuItem.AdvancedDrawItem(ACanvas: TCanvas; ARect: TRect; State: TOwnerDrawState; TopLevel: Boolean); Begin Self.DoAdvancedDrawItem(Self, ACanvas, ARect, State); End; Constructor THeaderMenuItem.Create(AOwner: TComponent); Begin inherited; Self.Enabled := False; OnAdvancedDrawItem := DoAdvancedDrawItem; End; Procedure THeaderMenuItem.DoAdvancedDrawItem(Sender: TObject; ACanvas: TCanvas; ARect: TRect; State: TOwnerDrawState); Begin ACanvas.Brush.Color := TStyleManager.ActiveStyle.GetStyleColor(scPanelDisabled); ACanvas.FillRect(ARect); ACanvas.Font.Color := TStyleManager.ActiveStyle.GetStyleFontColor(sfWindowTextNormal); ACanvas.Font.Style := [fsBold]; ACanvas.TextRect(ARect, ARect.Left + 3, ARect.Top + 3, StripHotkey(Caption)); End; Function THeaderMenuItem.GetEnabled: Boolean; Begin Result := inherited Enabled; End; Procedure THeaderMenuItem.Loaded; Begin inherited; Self.Enabled := False; End; Procedure THeaderMenuItem.SetEnabled(Const inEnabled: Boolean); Begin inherited Enabled := False; End; End.

My theory doesn't seem to work. I created a second design-time package and moved the property editors there as some property editors were using components which are to be installed in the very same package... no luck. Now the component package installs just fine, the package containing the property editors are throwing the errors. I read that the code in property editors have to be extra clean (no WITH statements, no "confusing" parts for the compiler) so I made a cleanup there too.

We had this issue at work, the root cause was a poorly written in-house IDE plugin. As others already mentioned - start uninstalling / disabling plugins and then component suites. You'll quickly find the culprit.

@chkaufmann This looks awesome! Btw add Vcl.Themes to your uses list and use TStyleManager.ActiveStyle.GetStyleColor and GetStyleFontColor to add VCL style support to your code. Questions, though: - If you hover your mouse on the header does it get highlighted? I guess not because state is ignored in general but worth to ask... - This is my bigger issue: clicking on a header will close the menu, right? Maybe this can be fixed by overriding protected methods of the TMenuItem / TPopupMenu

After some time investigating the issue I found out that custom property editors are causing this. We had about 4, removing one from the package caused the Internal Error to simply point to a different one. I have a theory which I will test out during the upcoming week(s). Will post an update once I have any news...

I just went to doublecheck, the runtime package is already included in the Requires section of my designtime package. Seems I added it, I just forgot 🙂

cds.Filter := 'MyField LIKE ''%contains%'''; cds.Filtered := True; ?

There is no automatic notification as far as I'm aware, but the app receives the WM_FONTCHANGE message which was broadcasted. In the discussion on GitHub I mentioned that if I put a label on the form, set the font name to the same as in the ListView and paste some characters it shows up correctly without PostMessage / Sleep. This makes me believe that the installation is successful, only GDI+ needs some time before it can access a freshly installed font (or implementation is not correct). Unfortunately I have zero experience with any graphic-related stuff so can not confirm / debug :( This is why it's not even viable as a workaround imo.

You mean a font is not meant to be installed runtime or not to be drawn with GDI+?