Lars Fosdal

XE7 was bad.

Usually, it seems to be related to something not compiling, and not necessarily in the unit that you are in.

If you use FireDAC, you can also use the FireDAC Monitor to capture everything that goes on, databasewise. http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Tracing_and_Monitoring_(FireDAC)

I have no experience with the MacOS shell, but a bit of googling dug up this? Not sure if appropriate. https://stackoverflow.com/questions/43020737/delphi-capture-osx-console-output

@Juan C.Cilleruelo - Do you invoke a new instance of OpenSCAD for each image? If you do, can't you execute it from a thread that waits for it to complete and return?

You are right, unless he is in control of the external program as well.

I have a DebugOut call that I mostly leave in the code as needed. By default it writes to OutputDebugString, but it also writes to a 4K line buffer internally, and I have patched the system menu to add a "Log to file" option. If the user enables logging to file, it first dumps the 4K line buffer then appends anything else being logged after that. For server apps, there is a midnight rollover routine that creates a new logfile, and deletes logfiles older than <configurable> days. As for adding / removing logging - I can ifdef or comment things in and out by hand, but mostly I just leave it in there, if it is not pure development test code, that is. More logging > less logging - when you actually need to figure out what happens.

I assume you are in control of the output location. f.x. %somepath%\generated\myimg.png What if you create a "signal" file that basically is the URL of your graphics output file with f.x. '.processing' at the end before you start generating the file? %somepath%\generated\myimg.png.processing Once the processing is complete, you delete the %somepath%\generated\myimg.png.processing That way, your other process could check if the file %somepath%\generated\myimg.png exists, but continue to wait if there is a %somepath%\generated\myimg.png.processing file there?

I think it looks good. It adds clarity and reduces clutter. I am slightly unsure of the [+] to > change for expansion in tree views, but we'll see.

Adding a few words about yourself is always useful.

The site header (blue, with Delphi-PRAXiS title) takes a little too much vertical space for my preferences.

Currency can hold Decimal(50,4) if I remember correctly. Extended could have worked, but strangely it's not available on 64-bit.

I agree. The post/comments could be condensed.

If you use Chrome on your family computer, you can have multiple user profiles and switch them there?

@NIRAV KAKU - have you tried the site on a mobile browser?

I welcomed ARC in principle, but there were three key problems for me:1. Having two different memory management models in our code base was not an option2. ARC carried an unexpectedly high performance penalty 3. The pitfalls of ARC were as many and as complex as for the classic reference count problems.

Check out the various options under Activity on the top bar. A lot of options there for different ways to spot activity.

I am a speed reader, and I would love we could create a super compact alternative somewhere down the line!

From my perspective, I am very glad to see that the Linux compiler will use the same memory management model as the Windows compilers. That makes it a lot easier for us to write cross-platform server code, something we have been pondering for a while.

It seems that my test dummy also sees the RSS streams - both for activity streams and for separate forums.

I'll make me a Lars FosTestDummy login to see how things look as a regular user. Introducing: https://en.delphipraxis.net/profile/119-lars-fostestdummy/

Works for me.

@Dany Marmur- Do you mind if we move this to the Delphi Third party section?

It responds at first click in Chrome Version 70.0.3538.77 (Official Build)

That highlighting is a tad confusing, indeed. Not sure if the active selection could be highlighted differently?