Closed a-nigredo closed 7 years ago
ok, I see. Do you have an estimation?
Do you want to make a pull request for it?
I'll try but can't guarantee that I'll be able to manage it since I'm newbie in Rust.
@pravic I've started implementing and have questions about the next signatures:
pub SciterSendEvent: extern "system" fn (he: HELEMENT, appEventCode: UINT, heSource: HELEMENT, reason: UINT_PTR, /*out*/ handled: * mut BOOL) -> SCDOM_RESULT,
pub SciterFireEvent: extern "system" fn (evt: * const BEHAVIOR_EVENT_PARAMS, post: BOOL, handled: * mut BOOL) -> SCDOM_RESULT,
Why do we need raw mutable pointers for variable "handled"?
@pravic I'm talking about type of variable handled. Why is it *mut? it might be just bool type I guess.
Because of /*out*/ BOOL* handled
- it is out argument.
Also I can't create mut pointer for boolean type is Rust.
let mut handled = false as BOOL;
let params = BEHAVIOR_EVENT_PARAMS::default();
let ok = SciterFireEvent(¶ms, false as BOOL, &mut handled);
if ok == SCDOM_RESULT::OK && handled {
// no error and behavior event was handled by element
}
Done in this and this commits.
However I found that send event feature mixes source and target elements, asked about it here: http://sciter.com/forums/topic/confusing-scitersendevent-k/.
But in general, why do you need this functionality in native code? Its easier (and better) to work with DOM via script, which can ask the native app about data and notify it about events.
A goal was studying Rust by implementing desktop application for company's backend system but finally I use script;)
You can study it providing high-level logic and data in app, leaving UI-related operations to UI level.
That DOM API in Sciter - legacy (and compatibility) from HTMLayout (the successor of Sciter), where you managed UI things from native code only.
yeap, that's why I migrate to tiscript
Enjoy then :)
Hi, @pravic. When are you gonna implement fire_event function for Element?