On 04/20/17 13:05, Eli the Bearded wrote:
> In alt.hackers, Big Bad Bob <BigBadBob-at...@testing.local> wrote:
>> On 03/06/17 18:09, Mark4Posting so wittily quipped:
>>> In May 2016 I got a DUI in Cobb County, Georgia, which is a county in
>>> Atlanta, Georgia.
>> not much of a hack there. In fact, it's just a request for someone else
>> to risk jail time to help YOU out of a self-inflicted legal problem.
>
> That post never made it to my server. I suspect self-moderation enforcement
> problem.
really? hmmm... well at least the NG is getting some activity.
> But it also turns out that every PHP file has a require() statement
> to load the same config file. So I've been filling that config file out
> with fixes. Like a new implementation of ereg() using preg_match().
that's actually pretty convenient. on occasion I've done similar things
when porting windows-based code to non-windows systems, writing a
compatibility function(s) and put it into a header file, use #define
macros to keep the code as intact as possible, etc..
maintaining old code is a hack in and of itself, sometimes. 'bleeding
edge' updates are highly overrated.
ObHack - using 'patch' concrete to build ramps, etc. for use inside a
desert turtle's living space, which has playground sand and river rocks
and other stuff in it. OK haven't actually done it YET, but I bought
the materials... but the turtle kinda needs a ramp to get in/out of the
pool of water. [right now it's possible for him by climbing on rocks,
which he does]
AnotherAndroidHack - Android development lacks a proper "message box"
function. It's painful to make things like that happen the way it does
"pretty much everywhere else" from GTK to winders. The best compromise
solution wasn't originally my idea, as I got the idea reading other
people's solutions. But I think I nailed how to use it properly.
In short, create a static utility function (member of a common class,
maybe 'MainActivity') where you pass in a message as a String. The
function will use 'builder' to create the dialog box, but also create a
'handler' that throws an exception when you message it. You have the
dialog box's button 'onClick' send a message to the handler when the
user clicks on a button (and indicate which button, maybe as a static
public variable for the class). THEN, after you create/display the
dialog box, you call 'Looper.loop()' within a try/catch block, expecting
the "exception" (I know, exception-based stuff is LAME, but this is the
only way to do it, apparently).
THEN, when the user presses/taps a button in the dialog box, it sends a
message to the handler, which throws an exception, and busts out of
'Looper.loop()', with the static public variable optionally containing
information about the button that was pressed/tapped.
Simple, clean, works.
This is MUCH better than having to process this sort of thing
asynchronously, having to break things up into chunks just to satisfy
Google's somewhat limited vision of how things need to be. And, for
other 'async things' (like bluetooth, web server queries, network
activity in general) where you can NOT use the main UI thread, you can
use similar techniques. One caveat: It doesn't work if 'Looper.loop()'
will cause things to screw up, so you have to limit (slightly) where you
do this. But your average 'onClick' handler for buttons and menus and
stuff does it just fine.
And while you wait, the rest of the UI behaves as it ought to, nice and
clean without stuttering nor stalling.