Thank you Bruce for finally explaining the rationalization and not responding in such a negative manner as others did.
Now for the million dollar question. What is too long? When should a loop proceed normally or be put in another thread, timer callback, etc. Is this determined by trial and error or some other method?
Is it our youthful avatar’s that make you think we’re all in academia?!? 
This is one of my smaller projects written over the last two years with JUCE…
(makes me realize I better start commenting more!)
Anyways, line counts, money earned, number of apps being used, it all really means nothing! Good coding practices are good coding practices, whatever the length of code you are writing! And as Vinn and Bruce and Jules have stated, blocking the event loop is not a good idea! I do sympathize though, I do remember (vaguely!) PowerPlant encouraging this kind of thing back in the day, but thanks to a steady diet of bourbon i’ve killed off those brain cells!
Well I want to thank the original poster for bringing me on this trip down memory lane…arguments from two decades ago…
Excellent question. Quite simple, although you have to account for the environment your app will run on. So,
Take the circumference of your noggin. Raise to the power of your shoe size. Divide by the number of Pringles in a tube (standard tube). Express as a fraction using base 3, then do a bitwise or with your home address in unicode expressed as binary.
The answer is in picoseconds, obviously. I like to add a safety factor - I generally use the distance of the Earth to the Moon, divided by the number of calories in a Starbucks Grande EggNog (no whipped cream).
Glad to be of help in your important quest to be correct.
Bruce
Now you’re talking about line-counts? It’s getting harder and harder to take you seriously… if anything, greater application size brings with it an increased chance of fragility, and a greater necessity for a robust approach.
Being a coder in the games industry, I can totally appreciate (and sympathise with) the necessity to ‘get things done’. In fact, if we’re playing this numbers game, I would wager that my deadlines are considerably tighter (and more densely packed) than yours! However, “get the result fast” does not equate to “get an equivalent result by any means necessary”. Sloppy coding and disregard for its implications will ultimately bite you (and the rest of your team) where it hurts.
Being cautious and careful is not a purely academic pursuit.
Being reckless and ignoring practical system limitations is simply not a professional attitude.
Just to make it clear, there are two separate issues here:
Blocking the event loop for too long without returning. Just blocking and doing a straightforward CPU-intensive task is bad practice, and creates a bad user experience, so yes, it’s bad… but in fact this is not what I meant when I’ve been telling you how dangerous it is. Yes, on iOS if you spin for more than a couple of seconds, then the OS will probably kill your app, but on desktop OSes you can spin for as long as you like without any actual bugs, just a very irritated user.
Polling the event loop from within the event loop. This is the really sinister, dangerous one. It’s the way people used to write code back in the old MacOS days when they had “TrackMouse” - you’d get a mouse-down, then within your callback, you’d run a mini event loop, waiting for the mouse-up. This creates so many opportunities for bugs that I can’t even begin to list them, because whenever you synchronously dispatch the event loop, you have no idea whatsoever what has happened to the state of your program when it returns. And afterwards, as your call-stack unwinds itself, any of the objects on it could have been deleted or changed in unexpected ways. Because this is so pernicious, modern OSes are getting tougher on all kinds of modal looping - in iOS the APIs calls to do it are deeply hidden (although it’s possible to find them if you’re cunning). On Android it’s completely impossible.
[quote=“FirePlayer”]OK I am curious here. How many of you on this thread have produced a retail program that is in existence and making money, let’s say over a 100k a year. How many of these were written in Juce? Just curious. It’s easy to be caught up in academics. Hey would you rather have the profits from Linux or Windows?
[/quote]
go and fix things instead of moaning about hacks that i’ve never seen on earth… blocking loops in mouse down… heck! and you think we are taking you seriously ?
i wouldn’t buy your stupid products now that i know they are made by a blatant crap-hack-a-coder 
jeez!
Could some forum admin rename the thread to “isButtonDown() [GENUINE TROLL INSIDE]” ?
I’m amazed the amount of bad faith and ugly argument going on in this thread.
Bruce, I like your formula, but it’s wrong. You forgot to take into account the weight of USA’s first lady, and to divide by the number of feathers on the lucky turkeys that were spared last week.
You might need to approximate the former, since it’s considered as a state’s secret.
To the OP, when you ask for something, and someone told you it’s possible but it’s a bad idea to do it, at least, you should start thinking about the reason.
From now, and your post, whatever code you’ll write will be taken with very very high bitter taste.
It’s sad, since you’ll soon realize that Juce’s code is probably one of the best from all GUI code I’ve worked with (speaking of QT, GTK, MFC, WTL).
It’s not the best in terms of features, Qt beats them all, but it’s clearly the best in terms of intuitive behaviour, function naming, documentation and, most important one, right design pattern choice.
Sure you can mess with point’s X and Y member directly (but what if you decide to name these members differently), but when you’ll be writing serious code, you’ll find out that each time you’re accessing x and y directly, you’re actually recoding an operation that’s already implemented (correctly) in the Point class. Finally, instead of unreadable code doing complex manipulation with cos & sin and probably errors, you’ll end up with code saying what the mathematical operation is (like “Point.rotated(Pi/8, center)” instead of the 4 lines of cos + sin variant that’s unclear).
BTW, it’s not because everyone shout that the truth is said.
Awesome. Looks like coders are at war again :mrgreen:
[quote=“X-Ryl669”]It’s sad, since you’ll soon realize that Juce’s code is probably one of the best from all GUI code I’ve worked with (speaking of QT, GTK, MFC, WTL).
It’s not the best in terms of features, Qt beats them all, but it’s clearly the best in terms of intuitive behaviour, function naming, documentation and, most important one, right design pattern choice.[/quote]
+1 to that. Qt suffers from needing that extra compiler support for that ridiculous messaging system.
I’d agree. At the time I looked, price of Qt was an issue, but in the end the preprocessing silliness, and the ‘mock native’ GUI put me off. Juce feels like the way C++ was always meant to work.
I guess that the OpenGL Renderer will close one gap with Qt. Integrating IntroJucer and Jucer would be another, and then the only big ticket item on my list would be the ability to serve a web app from the same code.
And that ‘event based’ thing ; )
Bruce
I don’t like needing to use IntroJucer or Jucer though…to me, that’s a step in the direction of Qt’s non-standard system. So far, we don’t “need” to use those Juce tools (I think?) but if it ever comes to where it is a requirement I think that’s a mistake.
Well, I really like being able to create controls and UI from code simply, yes. But a GUI tool is great for a starting point, or noodling with many controls, and it makes C++ usable for simple utility apps - one day systems.
As for Introjucer - I use it to kick things off. I don’t care to know all the intricacies of making projects in 4 dev environments for 6 platforms.
If I could whip up a simple GUI and output a project, then do touch-ups, I would use that a lot.
Bruce
I agree with TheVinn that the IntroJucer shouldn’t become a requirement. But the Jucer is really a time saving, moneymaking if you will, tool 
use of Juce and development with Juce is far better , easier and effective compare to QT for cross platform development with C++. Like (+1) to Juce.
Sorry to resurrect this tawdry thread, but I cam across a link that covers this issue:
http://slash7.com/2006/12/22/vampires/
Guess we might be getting a bit more of that?
For the curious, here’s the thread. Startlingly similar to this one:
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=307954&nt=2&page=1
Oh, and Merry Christmas!
Bruce
