Anders Melander

I think you are missing my point. I'm saying that SameValue, with Epsilon specified, is documented to work in the way it does now. If it didn't then that would be a bug. You can argue that it would be better if it worked in another way (e.g. Epsilon relative to the magnitude of value) but that is not how it is documented to work, it is also subjective, and it depends on how one intends to use it. It's like arguing that the right way to index strings is zero based.

Should? As far as I can tell the current implementation matches the documented behavior. Yours doesn't. You might prefer another behavior, which is perfectly reasonable, but it doesn't make the current one wrong. I agree that SameValue without the Epsilon parameter is at best problematic but, with regard to the choice of default Epsilon, we don't know what the criteria was for the values they chose (because it isn't documented) so I can't see how we can say that they are wrong. Again; We might prefer other values but that doesn't make the current values wrong.

Only if you don't specify a tolerance. I can't see anything wrong with it if you specify a tolerance.

Multiply by a 10^"number of decimals", Trunc to convert to integer, Assert on the integer value

As far as I can tell they've been forced to replace their proprietary APIs with standard APIs (in order to avoid vendor lock-in) and to allow competing third party applications access to their map data. Did I understand that right? It seems Google has few friends in the map business; They aren't allowed to link to Google Maps from their Google search results - or even from the search page (which is pretty stupid and doesn't do the users any good), while the same restrictions doesn't apply to Bing. Could it be that Bing map data is provided by Tom-Tom?

Alright then. So you are going to violate the license and don't want that aspect discussed. That's between you, Microsoft, and whatever unfortunate user/client, if any, this involves but maybe you shouldn't ask us to help you do it.

You mean you are "installing the software on a device for use only by remote users"?

No it's not; You are not allowed to use a desktop Windows as a server. What other people that violate the license say about that isn't really relevant.

Exactly. Read the EULA. Search for "server". It's stated pretty clearly what you can and cannot do.

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.