Anders Melander

Then I think you need to familiarize yourself with the Windows EULA.

So this is a hobby project. Right?

IOW, a failover cluster. Have you considered a Windows Workgroup cluster? I believe they can be built fairly cheap.

FWIW, madExcept didn't find any memory overwrites but of course caught the exception: exception class : EAccessViolation exception message : Access violation at address 58C66418 in module 'COMCTL32.dll'. Read of address 0000000C. main thread ($3be0): 58c66418 +000 COMCTL32.dll 74a25d96 +016 USER32.dll CallWindowProcW 00eb193d +131 Editor.exe Vcl.Controls 11199 +34 TWinControl.DefaultHandler 00eb246a +01a Editor.exe Vcl.Controls 11505 +1 TWinControl.WMCommand 00eac1b2 +2be Editor.exe Vcl.Controls 7920 +91 TControl.WndProc 00eb17e7 +6a7 Editor.exe Vcl.Controls 11154 +178 TWinControl.WndProc 00ece57f +23f Editor.exe Vcl.StdCtrls 4849 +95 TCustomCombo.WndProc 00ed02e4 +1f0 Editor.exe Vcl.StdCtrls 5642 +42 TCustomComboBox.WndProc 00e2f31c +014 Editor.exe System.Classes 19084 +8 StdWndProc 00eb0cac +02c Editor.exe Vcl.Controls 10823 +3 TWinControl.MainWndProc 00e2f31c +014 Editor.exe System.Classes 19084 +8 StdWndProc 74a260b8 +048 USER32.dll SendMessageW 74a25d96 +016 USER32.dll CallWindowProcW 00ed7310 +2bc Editor.exe Vcl.StdCtrls 11307 +70 TComboBoxStyleHook.ListBoxWndProc 00e2f31c +014 Editor.exe System.Classes 19084 +8 StdWndProc 74a2620b +00b USER32.dll DispatchMessageW 00f760bb +0f3 Editor.exe Vcl.Forms 13282 +23 TApplication.ProcessMessage 00f760fe +00a Editor.exe Vcl.Forms 13312 +1 TApplication.HandleMessage 00f7643d +0d1 Editor.exe Vcl.Forms 13451 +27 TApplication.Run 00ff37a6 +05a Editor.exe Editor 21 +5 initialization 75f7fcc7 +017 KERNEL32.DLL BaseThreadInitThunk

Isn't that stretching the meaning of mobile quite a bit - literally? I mean the UI looks like that of a regular desktop application. Never mind why, but how would you operate this on a phone?

My guess is that something you are doing elsewhere is corrupting memory and what you are seeing are just secondary errors. You can probably use madExcept, with memory overrun check enabled, to find the origin of the problem.

There are no rules against necro-posting; It's just pointless.

SHChangeNotify got me thinking... Assuming a call to SHChangeNotify(SHCNE_ASSOCCHANGED) is all that is needed to rebuild the cache, is there something in Windows that we know makes that call? A quick search of "the source" gave the answer: The assoc command of the Windows shell; All it does is write an entry to the registry and then make the SHChangeNotify call. assoc .foobar=text Voila! If you want to remove the file association entry again then it's just: assoc .foobar= Admin privs required, btw.

I used to be able to reset the cache without a reboot with: ie4uinit.exe -ClearIconCache or ie4uinit.exe -show but I haven't had much success with those methods lately. It definitely is possible to clear the cache without a reboot or killing explorer but it seems Microsoft doesn't want to make it easy for us. See: SHChangeNotify

If you mean to expose the TModel record from the TModels list encapsulation then you can do so by (also) exposing record pointers: type TModel = record Foo: string; Bar: integer; end; PModel = ^TModel; TModels = class private FItems: TList<TModel>; private function GetModel(Index: integer): TModel; procedure SetModel(Index: integer; const Value: TModel); function GetData(Index: integer): PModel; public property Items[Index: integer]: TModel read GetModel write SetModel; default; property Data[Index: integer]: PModel read GetData; end; function TModels.GetModel(Index: integer): TModel; begin Result := FItems[Index]; end; procedure TModels.SetModel(Index: integer; const Value: TModel); begin FItems[Index] := Value; end; function TModels.GetData(Index: integer): PModel; begin Result := @FItems[Index]; end; var Models: TModels; var Model: TModel; ... Model := Models[0]; ... Models[0] := Model; ... Models.Data[0].Foo := 'Hello world'; Models.Data[0].Bar := 42;

Because the TList<T>.Items property getter returns a read-only copy of the record. This is the same for all properties that return a record. You can use the TList<T>.List property to gain access to the internal array of TList<T>.

I agree - but here's a few examples of where I've used it: // Using absolute to rename a public API function while maintaining backward compatibility: // - MyFunction is the old API entrypoint. // - NewNameSameFunction is the new API entrypoint. type TMyDelegate = procedure(X, Y, Z: Single); var NewNameSameFunction: TMyDelegate var MyFunction: TMyDelegate absolute NewNameSameFunction deprecated 'Use NewNameSameFunction instead'; // Same with global vars: type TLUT88 = array[byte, byte] of byte; var DivMul255Table: TLUT88; MulDiv255Table: TLUT88; var RcTable: TLUT88 absolute DivMul255Table; DivTable: TLUT88 absolute MulDiv255Table; // Casting between "uncastable" types without pointers procedure FooBar(const X1, Y1, X2, Y2: Single) var Y1bin: Cardinal absolute Y1; Y2bin: Cardinal absolute Y2; begin // Fast way of testing if a Single is zero; Same as "if (Y1 = 0) and (Y2 = 0) then" but faster. if (Y1bin shl 1 = 0) and (Y2bin shl 1 = 0) then Exit; ... end;

If you mean the volatile thing then it's not a problem unless you are doing high performance low-level stuff. AFAIR the worst that can happen is that a value is kept on the stack instead of in a register.

Use High(MyArray) instead; It clearly communicates what your intentions are. IMO, using Succ and Pred for anything other than enumerations is like using Assigned on pointers (even object pointers). On delegates it makes sense, but for everything else I think (FooBar <> nil) is more readable and better communicate intention than Assigned(FooBar). I'm sure everybody agrees with me on that 😉

The only issue with absolute that I can think of is that the compiler treats the aliased variables as "volatile" which inhibits certain optimizations - AFAIR. Apart from that it's just like a hard typecast. Of course one has to avoid doing stupid things like using absolute on managed types.

What change? You mean a possible future change of the index type? I can't see how any of the Pred used here would survive that: TABLE_DATA: array[0..pred(TABLE_SIZE * 3)] of string Elements : array[0..pred(TABLE_SIZE)] of record Regardless, if I changed the index type I would want to review the implications of that change manually and not assume that it just worked - especially with absolute in the game.

I don't understand the question but... while absolute has its uses, in this case it would IMO just be laziness on the part of the developer. And what's up with the use of pred? Since when did that become more readable than -1 ?

Ouch. I think that article will do more harm than good (with regard to map2pdb). There are simply too many errors in it; E.g. all the command lines have been mangled. - and map2pdb has moved to Github: https://github.com/andersmelander/map2pdb

The eel is a critically endangered specie.

What are the benefits of Superluminal over VTune in your opinion? I looked at Superluminal a few years ago and AFAIR it didn't do anything that VTune couldn't do better - for free.

I don't get it. Isn't CreateParams called before the window handle is created? Then why would RecreateWnd be necessary?

5 months later?

You probably copy/pasted the code from here and therefore got the looks-like-space-but-isn't Unicode characters the forum pretty-printer sometimes uses. Type it by hand and it will most likely work. Apart from that, why are you even bothering with {$if declared} at all? Just declare the constant unconditionally, FSS. It's not like you will break anything if it's already declared.

Corrupted? Because of a missing declaration? There are lots of stuff missing, at any given time, since new values, structures, and functions gets added to the Win32 API all the time and Embarcadero can't keep up. PROCESS_QUERY_LIMITED_INFORMATION has been missing for ages. Just declare it locally and move on.