Ooops, previous post sent to fast. So I said, re-hello Sieghard.
Sorry to come one more time with the same song. But it would be *much* easier for me if you use GitHub site for all commits-code-discussion things. Have a perfect we. Fre;D ________________________________ De : Sieghard via mseide-msegui-talk <[email protected]> Envoyé : jeudi 10 novembre 2022 01:29 À : [email protected] <[email protected]> Cc : Sieghard <[email protected]> Objet : Re: [MSEide-MSEgui-talk] New release MSEide+MSEgui 5.6.10. Hallo Fred, vous ecrit au Mon, 24 Oct 2022 13:59:41 +0000: > There is a new release of MSEide+MSEgui: version 5.6.10. > That stable release has almost fixes of previous release. Sorry that I reiterate on the new release again. But I'm a bit puzzled over some modifications that I found and cannot find any reason for. When I recently scanned the lib/common directory contents again, I still found the "mse_dynpo" compatibility functions being completely ignored. And, moreover, you did introduce quite a number of tests for stock texts that, IMHO, cannot possibly be missing from the stock data structures, be them the olden static arrays or the mse_dynpo dynamic ones. That is, when the latter are accessed through the compatibility functions, because these DO provide a test whether the arrays have been initialized, and do it when not. The only instance that these data structures might NOT be available I can think of was if the compatibility functions were NOT used for accessing them, but then they will be missing in full. And then, what makes me puzzled most about your newly introduced tests - they ALL check for the arrays containig data beyond sc_All, disregarding the specific item used in the statement. And I cannot find any reason WHY this specific item, sc_All, should in any case be so special that it could create a limit position beyond which the arrays might not contain any more valid data? In fact, this should be impossible as long as compiler and the hardware of the executing machine were intact, as only a memory or processor, or possibly data transfer, failure could create such a situation. And why, then, should this specifically occur at the index value of "sc_All"? IMHO, you could do away with ALL of these tests when you just use the compatibility functions provided, what also makes the conditional compilation for the "mse_dynpo" case obsolete. In fact, for the previous release, I did just that and never found a problem, even though I usually compiled all the stuff with "mse_dynpo" enabled. I even had put together a collection of my modifications in the file "mseide-msegui-shadow.zip" on my web site's mse subpage. I'm about to update this for the new release, but I'm still a bit reluctant to post it because of the still possible real reason for your newly introduced tests for partial stock data arrays. Perhaps you DID run into a problem with these? If so, could you please give me a hint as to how and why this can happen and how to provoke it, so it can be repaired? Thank you, and keep up the good work! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- _______________________________________________ mseide-msegui-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
_______________________________________________ mseide-msegui-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
