aehimself

4 minutes ago, Henry Olive said:

How can i get THE FIRST WORD of a memo1.text ?

Var firstword = String(Memo1.Text).Trim.Substring(0, String(Memo1.Text).Trim.IndexOf(' '));

Ineffective, but will yield you results 🙂

But as I mentioned, this will work only in some cases. I'd recommend against using such a solution anywhere near production.

30 minutes ago, Lars Fosdal said:

No lingering BDS.exes for me.

Seems... you are perfect, too? 🙂

This won't work, you have to parse at least a little bit. E.g.:

-- This is a very good query
/* Just for extra complexity */ SELECT * FROM MyTable

is a valid SQL query.

Zeos has a SmartOpen property, so you can call .Open even on queries with no resultset returned - although I never tested this.

My personal solution is:

Function IsOpenQuery(Const inSQL: String): Boolean;
Var
 fword: String;
 tokenizer: TZTokenizer;
 token: TZToken;
Begin
 tokenizer := TZTokenizer.Create;
 fword := '';
 Try
  For token In tokenizer.TokenizeBuffer(inSQL, [toSkipUnknown, toSkipWhitespaces, toSkipComments, toSkipEOF, toUnifyNumbers]) Do
   If token.TokenType = ttWord Then Begin
                                    fword := Copy(token.P, 0, token.L).ToLower;
                                    Break;
                                    End;
 Finally
  FreeAndNil(tokenizer);
 End;

Result := (fword = 'select') Or (fword = 'show') { Or fword.IsEmpty };
End;

It uses Zeos's tokenizer for parsing so I don't have to worry about comments and stuff.

Although it works, it is still vulnerable to the fact that (probably) there are a lot more statements than SELECT and SHOW, which will return a resultset.

27 minutes ago, Mike Torrettinni said:

Never experienced any issue with updates, except when I tried fighting them 🙂

https://en.wikipedia.org/wiki/Stockholm_syndrome

1 hour ago, FPiette said:

You system must be badly configured. I never have a force reboot using Win10 PRO: the system tells me a reboot is required but don't reboot by itself (You can also set the working hours so that the system still reboot but only in the non-working hours). I suggest you have a better look at all the related setting. And also make sure you have the latest Windows 10. Currently this is version 21H1.

My thoughts exactly. I saw videos Windows rebooting itself on some live streams and conferences but never happened to me, not even once; and I was testing it from the first Insider build. I also have to admit that Microsoft did a great job around updates (less downtime, torrent-like downloading from Internet and neighboring PCs, active hour detection, etc); whoever says otherwise install Vista or 7 vanilla and try to patch it up to current.

I have a feeling that lots of absolute-negative opinions of Windows 10 would flip if only the logo would be Apple instead of Microsoft.

On 10/7/2021 at 12:39 PM, Uwe Raabe said:

A fresh VCL forms application shows a Delphi icon in front of the window title. What did you do to remove that?

Form 652. That's a pretty extended hello world collection!

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!

On 10/1/2021 at 2:11 PM, Fr0sT.Brutal said:

This was likely advised by an ill C-er to spread the C-style madness over another languages. AFAIK no language uses this mechanism besides C which kinda alludes.

Ah, so those are the C header files...?! Basically only the descriptors?

On 10/1/2021 at 2:11 PM, Fr0sT.Brutal said:

Yes and it makes source examining a real nighmare. Alas, there's no better option to avoid code duplication.

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.

53 minutes ago, PeterPanettone said:

Can you base your fanciful assumption on anything substantial?

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

9 hours ago, PeterPanettone said:

TZipFile Update to the form, removed unused button and added label to show the… 19 days ago

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.

2 hours ago, Anders Melander said:

Given the minimal market share of XP

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 🙂

1 hour ago, Ian Branch said:

Error Handling - Not worth it in this case.  This may get used once a month, if that.

It is intended to repeat every 60 secs as long as the message.txt lives.  Exiting the message.txt creating App deletes the file.

Try-Finally bloc - Yup, will do that.

TFileStream - Will look at.

 

Thank you for your input/suggestions.

 

Ian

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.

On 9/12/2021 at 12:43 AM, Ian Branch said:

Hi David,

I ended up writing a little App to write a 'message.txt' file to the Apps root directory.  It deletes it when I exit the App.

 

I then added the following code in a TTimer event..

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.

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