Richard Gaskin wrote:
Ben Rubinstein wrote:
...
> ... a simple statement, legal in the syntax, which crashed Rev
> with 100% reliability shouldn't be marked "critical" because
> it could only affect the programmer, who should know better.
What statement is that, and has it been fixed?
See
http://quality.runrev.com/qacenter/show_bug.cgi?id=1634
apparently fixed but I've never checked
...
Agreed on it's usefulness, but overriding the answer command seems a
workaround to a deeper issue: "exit to top" isn't honored when called
from within any modal dialog.
<http://quality.runrev.com/qacenter/show_bug.cgi?id=294>
If we address that root issue and added support for Cmd-. to invoke it
in that dialog (at least within the IDE), the "answer" command itself
would be fine.
> * RevBrowser responds to a javascript alert in the hosted page by
> invoking 'answer'. I'd really like to trap this - currently I can't
> see any way to do so. If I could override "answer", I'd have a
> method.
Custom-handling the JS alert sounds very valuable indeed, and while I
haven't done much with RevBrowser thus far I will be later this year and
may need that myself.
I wonder if this might be handled well with a property, maybe something
like "the JSAlert", which would let you assign any command in your
stacks to handle JavaScript alerts. If left empty, the current behavior
would remain.
Do you have a RQCC request for this?
http://quality.runrev.com/qacenter/show_bug.cgi?id=6986
My point is exactly that - I totally accept "if you need a custom behavior,
give it a custom name" - all the cases that I can think of where we do want to
override a built-in function are because that would give us a workaround while
waiting for communication with RevBrowser to be implemented, or for cmd-period
doing exit to top in all threads, etc...
We've recently begun a new project, for which we've settled on using Qt. Rev
would have been faster; but one of the reasons we decided against it was that
if you hit a problem with Rev, you may have no option but to take another
route; because you can't fix the problems, and you can't wait for RunRev to
fix them. (By contrast, Qt is just a set of frameworks - when push comes to
shove, if you need to, you can dig into the C++ code and fix it yourself.)
> ...but really I'm playing devil's advocate: I'm very happy with the
> trade-offs Scott Raney made that give us blazing speed.
Amen, brother. I loved it when C++ Journal wrote a review of my
Rev-build WebMerge app in which they mistakenly said it was written in
C. :) I wish I could take credit for that, but its performance has more
to do with Raney pruning the token table than my scripts.
Absolutely. I've replaced C code with Rev, and had it go faster; because (a)
Raney is a brilliant programmer and (b) his code is more optimised - it took
me so long to write the C code just to do the job, that it wasn't fast.
I'm going to stop doing devil's advocate now...
Ben
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
