- It needs to be a member of a TThread derived class
- You can't allocate nor define the record inside the procedure, it needs to be on the heap (global) and not on the stack (local) anyway
- You should use stdcall
- You should use PWideChar (the routine calls the widechar version anyway as per MSDN)
- You should copy in the Pwidechar, not assign the pointer.
AND this need SEH enabled for your complete FPC build (*everything* full fpc build, full library build)
I seem to remember I also protected the WideChar with a critical section, although that should not be necessary.
@engkin: How to adapt the assembly code to work on x86_64?
It seems that MS added a new function for Windows 10 SetThreadDescription
@PascalDoes anyone have working code for x86_64 to name threads for debugging?
Quote@PascalDoes anyone have working code for x86_64 to name threads for debugging?I just noticed that while debugging a specific thread, the gdb sends back the ThreadID(see screenshot). This can be used to add unique names to each thread created from your application. The name is virtual, but it will show up in Debug Windows-->Threads dialog. All you have to do is add a TList/TObjectList to TDebuggerIntf class(components/debuggerintf/dbgintfdebuggerbase.pp), the list will hold the name and ID of every thread you wish to monitor. When the gdb sends the notify message, you compare the ids with the internal list and assign the name accordingly. I'm not saying it's easy to implement but it can be done. As a second screenshot I attach all the relevant units.
I also had this idea. But will it need IPC to share the information
is there an object which is accessible from Lazarus and my app?