Anders Melander

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.

How exactly would GetClipboardOwner help here? Did you read the whole thread before posting?

That's not Pascal. It's... Visual Basic. 🤦‍♂️

Thanks. It would but something like this shouldn't have passed internal QA in the first place. A compiler engineer would have known that the first thing you do when solving something like this is to write a regression test to first reproduce the problem and later verify that it is fixed. Maybe it would be a good idea if they hired some - compiler engineers, that is.

I think the comment refers to the 64-bit compiler, so that's what I'm asking about. I assume the 64-bit target is okay but since Embarcadero doesn't really provide any useful info (in any of the issues) it's just an assumption.

@Uwe Raabe Can you confirm that RSS-3102 (the record constrain thing) is fixed for 64-bit also? The last comment on the issue claims it isn't.

Looks good. You're leaking the TGeneratedRandomStream object though.

I'm apparently not getting the message through; There is nothing special required, by neither the source nor the destination, in order to support copy/paste of files via RDP. The RDP support is transparent. If your remote application copies data onto the clipboard in the FileContents & FileGroupDescriptor formats, then the local destination will be able to paste it. Waitamoment.. I just realized that you just used remote desktop as an example. You will not actually be using remote desktop. Is that correct? So you are actually just asking how remote desktop makes the remote clipboard available to the client and how to replicate that functionality in your own client/server system. Well, I don't know the exact details of how it's done but I know enough about the clipboard and dragdrop that I can guess. On the server, the RDP host monitors the clipboard (there's an API for that). When data is copied onto the clipboard, in one of the formats supported by RDP, the server sends a message to the client with the meta data (data formats, size, etc.) of the clipboard data. On the client, the RDP client receives the message and copies the (meta) data onto the local clipboard using an IDataObject interface. On the client, some application pastes from the clipboard... The local clipboard asks the local data source, via the IDataObject interface, for the data. The local RDP receives the data request on its IDataObject interface and forwards this request to the remote RDP server. The remote RDP server in turn does the same: It asks the remote clipboard for the data, the remote clipboard asks the remote data source (whoever copied the data onto the clipboard in the first place), etc. Once the remote RDP server has the data it sends it back to the local RDP client which then supplies it, through the IDataObject, to the local application. Done. Paste complete. A normal paste can cause data to be sent back, through IDataObject, notifying the source about the paste. I don't know if RDP propagates this information all the way back to the server.