My take is you have three options.
1. Get different requirements so it is not needed at all.
2. The tree is going to be very shallow. And probably very short. So roll your own.
3. This isn't going to work.
Why the third? For example sometimes I recurse a directory tree via the command line looking for files or even all files. I can certainly view that in a console but it is basically worthless because there is so much data. Even if I am just looking for one specific file I still need a search mechanism. So I route to a file and then use an editor to search.
But lets say you are not looking for a actual file system. So what is the growth rate of this tree? If it is shallow and small in 10 years rolling your own still works. And the users can use it. But if your growth rate is not small then in 10 years the users will have something they can't use.
If I was asked to do this and I already knew that the tree was not small then I would push back on the requirements. In writing (like email.) And if they insisted I would first make a copy of that email and my response. Then I would just roll my own (still not that hard.) It would be their problem when it was unusable. But I might use a demo with data from 10 years from now - just so they can see what is going to happen.
"Columns" are an illusion. If you only have "one column / item / field" (that you can identify), concatenate multiple fields together (as strings) with padding and / or a "separator" (e.g. "|")
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
I am getting a heap corruption. I am running under the visual studio debugger. and the exception is at
My scenario is I have a DLL reading and formatting data for a .exe. I keep a record count so when I get a exception, at
I insert code if (recordcount == 0x0000196e) __debugbreak; I then start stepping through the code looking for the problem how ever when stepping through the code works I try this multiple times however when I stop the code where the exception were to occur it always complete successfully
The listing I am trying to to inset in the richedit is huge about 153 pages 30 lines to page, 134 bytes across I roughly calculate the number of bytes I am trying to insert into the richedit is 1.6 meg. I am not sure if the size is the issue I do a Rciheditctrl::LimitText with the amount bytes I need
Again when break on the offending record and step thru the code it completes normally
Here is the stack frame My code starts a the DriveRichedit.exe
riched20.dll!CTxtPtr::InsertRange(long,unsigned short const *) Unknown
riched20.dll!CRchTxtPtr::ReplaceRange(long,long,unsigned short const *,class IUndoBuilder *,long,long *,unsigned long) Unknown
riched20.dll!CTxtRange::ReplaceRange(long,unsigned short const *,class IUndoBuilder *,enum SELRR,long *,unsigned long) Unknown
riched20.dll!CTxtRange::CheckLimitReplaceRange(long,unsigned short const *,int,class IUndoBuilder *,unsigned long,long *,long,int,unsigned long) Unknown
riched20.dll!CTxtRange::CleanseAndReplaceRange(long,unsigned short const *,int,class IUndoBuilder *,unsigned short *,long *,unsigned long) Unknown
riched20.dll!CLightDTEngine::ReadPlainText(class CTxtRange *,struct _editstream *,int,class IUndoBuilder *,long) Unknown
riched20.dll!CLightDTEngine::LoadFromEs(class CTxtRange *,long,struct _editstream *,int,class IUndoBuilder *) Unknown
riched20.dll!CTxtEdit::TxSendMessage(unsigned int,unsigned __int64,__int64,__int64 *) Unknown
user32.dll!CallWindowProcAorW(__int64 ,struct HWND__ *,enum _WM_VALUE,unsigned __int64,__int64,int) Unknown
mfc140d.dll!CWnd::DefWindowProcA(unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 1100 C++
mfc140d.dll!CWnd::WindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2100 C++
mfc140d.dll!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 265 C++
mfc140d.dll!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 418 C++
mfc140d.dll!AfxWndProcBase(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 299 C++
user32.dll!SendMessageInternal(struct HWND__ *,unsigned int,unsigned __int64,__int64,int) Unknown
mfc140d.dll!CRichEditCtrl::StreamIn(int nFormat, _editstream & es) Line 775 C++
> DriveRichEdit.exe!CProgDebug::OnInitDialog() Line 136 C++
DriveRichEdit.exe!CMainFrame::PROGDEBUG() Line 48 C++
DriveRichEdit.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 26 C++
We don't know which examples you've been looking at. But the whole point of thread-local storage is that it's local to the thread; one thread cannot modify a TLS variable for another thread. (At least not without jumping through several flaming hoops whilst drenched in LPG and holding a large firework.)
Each thread gets its own copy of the TLS variable. If thread A set it to 5, and thread B sets it to 6, thread A will still see it set to 5.
The DLL is being loaded into the virtual address space of the current process as a result of the process starting up or as a result of a call to LoadLibrary. DLLs can use this opportunity to initialize any instance data or to use the TlsAlloc function to allocate a thread local storage (TLS) index.
As far as I can see, that will only ever happen once per process. And the documentation explicitly says that this is the correct time to call TlsAlloc.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Just realized posted to wrong forum however the variable is in static or global storage the next thread that comes by can change its value thats my problem just about all the. examples for TLS and DLL s have it this way
I'm not sure I quite understand what you are asking, but each thread gets its own stack (pointed at by SP) which provides all the thread local storage. It can also allocate its own storage through the normal methods. You have not really explained what g_dwThreadIndex is being used for in relation to the question. Does this all relate to some article, or specific MSDN page?
Richard I think I’m begging to understand the source of my confusion
First it is my understanding there are Two types off DLL one for the entire operating system in my case windows 10 and one servicing threads of one address space if it’s the former I mean that works like USER.DLL then the code example of tls wouldn’t work an I right in this ?
No there is only one type of DLL, which is a Dynamically Loadable Library. However, it may, or may not, be thread safe, depending on how it is created. Most (all?) of the Windows provided DLLs are thread safe. And the whole point of having DLLs is that the system only needs to load it once, to service multiple executables (i.e. address spaces). Be that as it may, I am still not sure what your concern is with regard to threads.