I've been there. It's not Bootstrap though. It's the DOM in general. Every browser will refuse to fire input events on disabled form controls. For clicks this makes enough sense, but I've never heard anyone defend it as sensible behaviour for mouse movement events. It's just one of dozens of parts of the DOM that work the way they do because every browser vendor saw every other browser vendor doing roughly the same thing and decided it was the de facto standard. The W3C says nothing on the issue, and nobody cares enough to bring it up.
The usual workaround is to bind the handler on a containing parent element instead. Typically (in most browsers that I can recall), the events will still bubble up the DOM tree, even if they don't fire on the disabled element itself. If you find a browser where that's not the case, the uglier workaround is to put an invisible absolute container on top of the disabled element, and let that catch the events instead.
I've been there. It's not Bootstrap though. It's the DOM in general. Every browser will refuse to fire input events on disabled form controls. For clicks this makes enough sense, but I've never heard anyone defend it as sensible behaviour for mouse movement events. It's just one of dozens of parts of the DOM that work the way they do because every browser vendor saw every other browser vendor doing roughly the same thing and decided it was the de facto standard. The W3C says nothing on the issue, and nobody cares enough to bring it up.
The usual workaround is to bind the handler on a containing parent element instead. Typically (in most browsers that I can recall), the events will still bubble up the DOM tree, even if they don't fire on the disabled element itself. If you find a browser where that's not the case, the uglier workaround is to put an invisible absolute container on top of the disabled element, and let that catch the events instead.
I've been there. It's not Bootstrap though. It's the DOM in general. Every browser will refuse to fire input events on disabled form controls. For clicks this makes enough sense, but I've never heard anyone defend it as sensible behaviour for mouse movement events. It's just one of dozens of parts of the DOM that work the way they do because every browser vendor saw every other browser vendor doing roughly the same thing and decided it was the de facto standard. The W3C says nothing on the issue, and nobody cares enough to bring it up.
The usual workaround is to bind the handler on a containing parent element instead. Typically (in most browsers that I can recall), the events will still bubble up the DOM tree, even if they don't fire on the disabled element itself. If you find a browser where that's not the case, the uglier workaround is to put an invisible absolute container on top of the disabled element, and let that catch the events instead.
I've been there. It's not Bootstrap though. It's the DOM in general. Every browser will refuse to fire input events on disabled form controls. For clicks this makes enough sense, but I've never heard anyone defend it as sensible behaviour for mouse movement events. It's just one of dozens of parts of the DOM that work the way they do because every browser vendor saw every other browser vendor doing roughly the same thing and decided it was the de facto standard. The W3C says nothing on the issue, and nobody cares enough to bring it up.
The usual workaround is to bind the handler on a containing parent element instead. Typically (in most browsers that I can recall), the events will still bubble up the DOM tree, even if they don't fire on the disabled element itself. If you find a browser where that's not the case, the uglier workaround is to put an invisible absolute container on top of the disabled element, and let that catch the events instead.
That's not sufficiently hacky.
Build your own button control with hookers and blackjack and when it's 'disabled' instead just restyle it and rebind the click event to a different or no handler.
That way you can give a sufficiently large aneurysm to the next person to maintain it.
I've been there. It's not Bootstrap though. It's the DOM in general. Every browser will refuse to fire input events on disabled form controls. For clicks this makes enough sense, but I've never heard anyone defend it as sensible behaviour for mouse movement events. It's just one of dozens of parts of the DOM that work the way they do because every browser vendor saw every other browser vendor doing roughly the same thing and decided it was the de facto standard. The W3C says nothing on the issue, and nobody cares enough to bring it up.
The usual workaround is to bind the handler on a containing parent element instead. Typically (in most browsers that I can recall), the events will still bubble up the DOM tree, even if they don't fire on the disabled element itself. If you find a browser where that's not the case, the uglier workaround is to put an invisible absolute container on top of the disabled element, and let that catch the events instead.
That's not sufficiently hacky.
Build your own button control with hookers and blackjack and when it's 'disabled' instead just restyle it and rebind the click event to a different or no handler.
That way you can give a sufficiently large aneurysm to the next person to maintain it.
I was going to say you could make a CSS element for the button. Change it to that when it's "disabled" and then change the onClick to display a popover.
KakodaimonosCode fondlerHelping the 1% get richerRegistered Userregular
It should be a really simple concept. If you don't want me calling you at 1 in the morning, don't have your process generate 5000 errors a minute. Because if I get an alert about a server in the middle of the night, that server better be on fire.
And telling me "Oh, that's not a critical error." does not make me any happier.
0
Options
gavindelThe reason all your softwareis brokenRegistered Userregular
I managed to corrupt both of my dev machines, woo! I have spent all morning rebuilding the VMs from scratch. My own fault, I suppose. At what point in sane development is "eh, delete this and see what happens" reasonable?
I managed to corrupt both of my dev machines, woo! I have spent all morning rebuilding the VMs from scratch. My own fault, I suppose. At what point in sane development is "eh, delete this and see what happens" reasonable?
Always? That's why we have VMs, right?
+1
Options
gavindelThe reason all your softwareis brokenRegistered Userregular
I managed to corrupt both of my dev machines, woo! I have spent all morning rebuilding the VMs from scratch. My own fault, I suppose. At what point in sane development is "eh, delete this and see what happens" reasonable?
Always? That's why we have VMs, right?
You're right.
I should have run that experiment on the public test VM.
Also, isn't that the point of having VMs? That you can keep snapshots of them if they get messed up and restore to like, a few days ago at worst?
+4
Options
gavindelThe reason all your softwareis brokenRegistered Userregular
So the solution was a semaphore that got written to the database and abandoned as active by one of my crashed batch jobs. Took the right engineer lead all of 15 seconds to call it.
Though my solution of "Nuke everything" did work, in my defense!
Maybe a dumb question. I'm trying to teach myself a bit more about android apps and have no idea where to start. I'd like to make something simple like a Choose Your Own Adventure type thing. This Lifeline game I'm seeing seems similar to what I'd like to experiment with making. Would I just go through the Android Studio thing?
SniperGuy on
0
Options
thatassemblyguyJanitor of Technical Debt.Registered Userregular
Maybe a dumb question. I'm trying to teach myself a bit more about android apps and have no idea where to start. I'd like to make something simple like a Choose Your Own Adventure type thing. This Lifeline game I'm seeing seems similar to what I'd like to experiment with making. Would I just go through the Android Studio thing?
Yeah. Definitely go through the process of installing the Android Studio toolkit.
However, a lot of the GUI widgets that you see in the app you're referencing was probably a non-trivial amount of custom work; even though it is mostly text based.
It's not insurmountable, and a pretty fun ride (disclaimer: Java :rotate:) Go through some of the tutorials, download some of the example projects, and you should be able to get something off the ground.
+1
Options
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
edited September 2015
Orrrrr you could do a hybrid app
which is basically html/css/javascript that you then use something like cordava or PhoneGap to compile out to ObjectiveC or Java to work as an app on mobile devices.
which is basically html/css/javascript that you then use something like cordava or PhoneGap to compile out to ObjectiveC or Java to work as an app on mobile devices.
My business is officially moving away from the consulting model and restructuring. By January, 90% of our income should be coming from our new product and doing random services for customers will be gone.
We're also doing this weird quasi-startup thing now? Where the owner is looking for angel investors so he can grow the company. But we aren't a startup, because we actually make profit and can support the company's bills without investing...I dunno, it's weird!
Steam: Spawnbroker
+4
Options
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
product based software engineering is soooooo much better than service/consulting based.
gavindelThe reason all your softwareis brokenRegistered Userregular
After hours of crap. I have finally pinned down the issue with my batch job. The first and second subjobs were tracking record id's separately. They started off synced. However, on some subsequent run, the first subjob would attempt to insert a claimed record id, hit the existing one, fail. Now, to add insult, the failure would force an abort and a rollback, wiping both sets of record id's back to their initial, synced state. You would be left with a duplicate error log to a DB record that didn't exist and a stack trace which worked every time.
How do you guys normally handle dependencies for code on a revision system?
Should I just add a 'dependency' folder and drop all the libraries in there (mostly dlls) ?
Or is it usually a separate project?
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
mightyjongyoSour CrrmEast Bay, CaliforniaRegistered Userregular
We do ours as separate projects. But we also package/install them separately from the rest of our software. On windows since you usually package everything together (I think, not a windows dev) then a dependency folder is probably ok.
Posts
The usual workaround is to bind the handler on a containing parent element instead. Typically (in most browsers that I can recall), the events will still bubble up the DOM tree, even if they don't fire on the disabled element itself. If you find a browser where that's not the case, the uglier workaround is to put an invisible absolute container on top of the disabled element, and let that catch the events instead.
narrows eyes
DOM.
Grrrrrrrrrgghrghghhghrghrhg
one of us
one of us
That's not sufficiently hacky.
Build your own button control with hookers and blackjack and when it's 'disabled' instead just restyle it and rebind the click event to a different or no handler.
That way you can give a sufficiently large aneurysm to the next person to maintain it.
I was going to say you could make a CSS element for the button. Change it to that when it's "disabled" and then change the onClick to display a popover.
Although, to be fair, before I had used hg or git, I used svn's branches only sparingly.
Try to run concurrently? Burn in hell!
And telling me "Oh, that's not a critical error." does not make me any happier.
Always? That's why we have VMs, right?
You're right.
I should have run that experiment on the public test VM.
Though my solution of "Nuke everything" did work, in my defense!
all those philosophers trying to eat with insufficient cutlery.
Uhh, damn.
yeah, that was how I felt last week.
niiiiiice
Doing enough of that personally now and not as an employee that I finally had to register for GST and bill that out. :rotate:
In the US you'd hold at least 40% to be "sure".
Yeah looks like it's about the same.
Yeah. Definitely go through the process of installing the Android Studio toolkit.
However, a lot of the GUI widgets that you see in the app you're referencing was probably a non-trivial amount of custom work; even though it is mostly text based.
It's not insurmountable, and a pretty fun ride (disclaimer: Java :rotate:) Go through some of the tutorials, download some of the example projects, and you should be able to get something off the ground.
which is basically html/css/javascript that you then use something like cordava or PhoneGap to compile out to ObjectiveC or Java to work as an app on mobile devices.
( if you go this route i reccomend http://ionicframework.com/ )
OR
you could use React Native ;P
JAVASCRIPT EVERYWHERRRRRRRREEE
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
That will not help to teach him about android apps
My business is officially moving away from the consulting model and restructuring. By January, 90% of our income should be coming from our new product and doing random services for customers will be gone.
We're also doing this weird quasi-startup thing now? Where the owner is looking for angel investors so he can grow the company. But we aren't a startup, because we actually make profit and can support the company's bills without investing...I dunno, it's weird!
like
it's night and day.
at least in my experience
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
Good God!
Should I just add a 'dependency' folder and drop all the libraries in there (mostly dlls) ?
Or is it usually a separate project?
Right after we got done ragging on others about doing that.
ask and ye shall receive
https://github.com/facebook/react-native/commit/42eb5464fd8a65ed84b799de5d4dc225349449be
"If you're going to play tiddly winks, play it with man hole covers."
- John McCallum
it is now!
https://code.facebook.com/posts/1189117404435352/
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!