Wow, that's a lot of feedback in a short timespan
Here's my take on the issues with string literals being returned from functions:
Literal strings are stored and referenced directly in the executable generated by the compiler. This is not a problem for calling functions or initiating dynamic strings with; it's just a pointer to whatever area the string resides in. However, when used to return from a function, it appears the DBPro runtime assumes that this is a "DBPro string". These are stored in a matrix held in dynamic memory and are what are used whenever you declare and use string variables / arrays. This system is used so that the runtime can overwrite or reallocate strings as necessary when their stored text changes. All remaining such string memory is released when the application exits. Herein lies the issue; the DBPro runtime will attempt to free the non-dynamic memory holding these return strings at shutdown. Memory allocation / deallocation functions are fickle and this
may occasionally not cause any visible issues, but most of the time it will cause an access violation crash. For some reason the string "update" (reallocation) routine can get called if a function returning a string is repeatedly called as well. This probably happens because the string is considered to go out of scope when the function returns, however it doesn't
always happen, which is strange. May be there is some lazy deletion scheme at work, or the runtime correctly determines that the string is not in dynamic memory
sometimes, but not always.
Furthermore, DBPro uses a 2D matrix for storing strings; essentially you have an offset into a string table, which contains a pointer to the actual string data. As an empty string is represented in memory simply as a zero byte, the likelihood of "success" with an empty literal string is higher as a pointer to it, which doesn't point to another pointer to the string but to the string data itself directly, as it will be interpreted as a null pointer and ignored. This only happens if the adjacent three bytes also are 0, so it isn't guaranteed to work, but as padding is usually employed it is somewhat likely.
WickedX wrote: "Since my beginning using DBPro, I have read posts concerning issues with returning string literals."
sladeiw wrote: "The string literals problem appeared with Windows 7 (possibly Vista). On XP it was fine to return string literals from functions."
This is what I remember as well. I don't recall it working on XP, but it has been many years since I used that so it is definitely possible it did. It would at first glance seem more likely that an update from the post-XP era is what broke it, however XP may have been more lenient with its memory allocation functions as well.
@Ortu: Does that program crash for you when you close it? If not, what happens with a longer string (17+ characters)?
Mage wrote: "Conclusion:
Everyone seems to be right."
Isn't that awesome when it happens?
Mage wrote: "There is an bug, DBPro 9Ex will not let ExitFunction command return a string at all. EndFunction seemingly unaffected."
This is correct, my exit-function check accidentally declines both literal and "normal" strings. I will put up a fix for this as soon as I'm able to, hopefully later tonight.
WickedX wrote: "By default 9Ex will compile the file and not the changes made in the editor. If you havn't already, try saving the file after making the changes then compile."
This is controlled by the following settings in the
Compiler\setup.ini file:
Quote: "[PRECOMPILER]
UseIDESourceDump=Yes/No"
If that is set to "Yes", the source dump of the IDE will be used. This has the drawback that correct line numbers may not be displayed in error messages for multi-file projects, but it doesn't require saving all source files on compilation.
If it is not specified in there it will default to "No", in which case files must be saved, as WickedX said.
This INI-file is not included when you download DBPro9Ex so as to not overwrite whatever personal settings you may have in there since earlier.
@CSL: Thank you, I'm glad you appreciate it
CSL wrote: "I wanted to start with one tiny observation about the version number. It displays 1.0.0.4 on the Help menu although the rar file shows 1.0.0.5. So I'm not sure what I really got installed."
Ah yes, this was an accident. The dialog displayed by the "About" menu in the editor resides in a separate dll file that I forgot to update for the latest release.
You can right-click on the <DBPro installation path>\Compiler\DBPCompiler.exe file and check it's "file version" attribute to verify the compiler version.
CSL wrote: "The first program I tried to compile received a compile error that has stumped me.
"Parameter for 'SPRITE' do not match 'Sprite Number, XPos, YPos, Image Number' at line 1765."
Line 1765 has the following code: «...»"
There is nothing wrong with that particular code line, which compiles and runs as expected for me.
There are a few possibilities here, the first being that the reported line is incorrect (see the section above). Have you checked a few lines up and down around line 1765 to see if the offending code may be there instead?
Another possibility again related to the above section; try to make sure you re-save all your source files and try to compile the project again, in case the UseIDESourceDump setting is set to "No" and this was an error you had but have now fixed since the last source save.
Mage wrote: "I had to delete D3D_TEXT commands used by Cloggy's D3D Func Plugin otherwise I get this error: «...»"
You get that error if there is an attempt to update a non-dynamic image. This can happen if a dll creates them itself, have you tried calling ENABLE VIRTUAL TEXTURE MANAGEMENT before whatever code causes that?
If that doesn't help there may still be cases where my workaround for this isn't fully functional, so if you could isolate some code that reproduces it that would be helpful.
Again, thanks for your interest in this project and your testing