Barton Bresnik wrote: > This issue may trace back to MS Windows API: memory must be allocated > for the title. If you set the title at design time, Delphi is usually > intelligent enough to pre-allocate the memory. At run time, setting > it equal to a string value will crash an app, because strings are > lifetime-managed: once it goes out of scope (e.g. at the end of a > procedure), the title points to an invalid location.
You're obviously very confused. Think about it: When does the scope end for the main begin-end block? When does the program terminate? By your logic, _any_ use of a string literal inside a subroutine would cause programs to crash. String literals are not allocated at run time. They are allocated at compile time and have special reference-count values that indicate to the RTL that they should not be managed the way normal strings are. They are not destroyed when a variable holding one goes out of scope. Furthermore, a string value can't actually go out of scope. Only variables have scope. A variable can hold a value. When the variable goes out of scope, the value in that variable has its reference count decreased (unless it's a literal value). If the reference count reaches zero, then the string value's memory is freed. By assigning a value to Application.Title, the string's reference count is increased because the Application object holds an additional reference to it, beyond whatever reference count the value had before the assignment. (Unless it's a string literal, in which case the reference count remains at the same special value.) > Work-arounds: global strings that last the lifetime of the app; > allocate memory for a buffer; allocate an array of char... Of course, manually allocated buffers and arrays of Char aren't strings, so you can't assign them to Application.Title. You or the compiler would need to convert them to strings, at which point you'd be back at the same problem you thought there was before. (But there is no problem with memory management, so that's OK.) The problem lies squarely with the IDE's insistence on a particular structure of the DPR file. -- Rob _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
