main problem is with scintilla SCI_SETTEXT message
which work in old version of oxygen BUT not in last release...why ?
Aurel,
You shouldn't underestimate the gravity of your filter string problem. It's nature is unpredictable and it may change its behavior randomly under different Oxygen versions that generate different data layouts in the process heap.
The two zero bytes at the end of it are a formal attribute of the end of filter string that signals the File dialog function to stop chopping the string into zero terminated chunks for the dialog's file type prompt combo. If the process heap memory that surrounds your malformed filter string is (unpredictably) tightly packed with meaningful data
and there are no two successive zeros found, the function will carry on chopping memory in pieces until it finds (asolutely unpredictably again) a succession of at least two consecutive zero bytes somewhere else. God knows how much valuable data, possibly including that which is related to your edit or Scintilla control calls/messages, may get corrupted in this process.
To kill the bug reliably, you should eliminate
all possible bottlenecks that are evident from your code analysis.
i don't know
To be absolutely sure it won't happen, I'd suggest you do it according to the classic and safest C-style algo:
1. Count the sum of lengths of all the file descriptions and extension patterns that will form up your final filter string.
2. Add the number of zero bytes in between the descriptions and patterns and the two trailing bytes to the above sum.
3. Allocate a fixed-length string buffer (or a byte array) filled with zeros to a length at least equal to the above sum.
4. Use RtlCopyMemory() from kernel32.dll or memcpy() from msvcrt.dll to copy your file description strings and extension patterns successively one after another into that buffer allowing for exactly one zero byte in between them and make sure there are at least two trailing zero bytes at the end of the buffer.
5. Assign the pointer to that string (or byte array) buffer to the lpstrFilter member of OPENFILENAME structure.
Hope this helps to at least make your File Open dialog call programmatically clean.