Crystal Reports: why is memo-type field truncated at 255 characters

This should do it:

stringvar output := {TABLE_NAME.FIELD_NAME};
output := Trim(output);  //get rid of leading & trailing spaces
output := Replace(output,Chr(13),'');  //get rid of line feed character
output := Replace(output,Chr(10),'');  //get rid of carriage return character

//add any other special characters you want to strip out.

If you have a lot of characters to strip out, you can use this slightly fancier approach. Just add whatever characters you want to strip out to the in[]:

stringvar input := {DROPME.TEST_FIELD};
stringvar output := '';
numbervar i;

input := Trim(input);

for i := 1 to Length(input) Step 1 do
  if not(input[i] in [Chr(13),Chr(10)]) then
    output := output + input[i];

output

The game development world is a funny one: On one hand, they're often quick to accept new ideas, on the other hand, they're still in the stone age.

The truth is, there's rarely that much incentive in switching to .NET/Java/anything other than C/C++.

Most game companies license parts of the game engine from other companies. These parts are written in C++, and although you might have access to the source so you could port it, that takes a lot of effort (and of course, the license needs to allow it).

Also, a lot of legacy code already exists in C++. If code from previous projects can be reused (say, if you're writing a sequel), that counts even more in favor of sticking with the same language, instead of rewriting it in a new language (more so since you'll likely reintroduce a ton of bugs which you'll need to spend time ironing out.

Finally, it's rare for games to be written in 100% C++ anyway - a lot is done using scripting languages, whether they're custom or just integrating an existing languages (Lua being one of the more popular ones these days).

As far as garbage collection is concerned, that can be a bit of a problem. The problem is not so much that it exists, it's more how it works - the garbage collector MUST be non-blocking (or at least be guaranteed to only block very briefly), since it's simply unacceptable to have the game freeze for 10 seconds while it scans all the allocated memory to see what can be freed. I know Java tends to choke quite a bit in GC'ing when it's close to running out of memory (and for some games out there, it will).

You're also a bit more restricted in what you can do: you can't fully exploit the hardware due to the overhead of the runtime. Imagine Crysis being written in Java... even if that's the only visible difference, it just wouldn't be the same (I'm also pretty sure you'd need a Core i7 to run it.).

This doesn't mean these languages don't have their place in game development - and no, I'm not just referring to tool programming. For most games, you don't need that extra bit of performance you get from C++, including 3D games, and if you're writing it all from scratch, it can make perfect sense to use something like XNA - in fact, there's a good chance it will.

As far as commercial games are concerned - does RuneScape count? That may well be the most succesful Java game out there.