• @user81574, I suggest you move on with PaddeK's code. Again, thanks @PaddeK for sharing. It does not need much to get it to completion for enroll and the other functions you would like to have at your (coding-)finger-tips. (Sticking on my path would over several serious transformation steps - such as adding the parser and promise - lead to a solution too... but I like to use invented wheels... in favor of saving the - non-recoverable - resource called Time for getting after the not yet invented ones...).

    For example, for the enroll function, just add the application callback into the method signature (line 11):

    ...function(id, callback) {
    

    and use it (in lines 21 and 22):

            let errorHandler = (err) => { ledOff(); reject(err);
                        callback(err, { _: me, id: id }); },
                successHandler = () => { console.log('enroll success'); resolve();
                        callback(undefined, { _: me, id: id })};
    

    If you want to have your callback execution to happen in its own Espruino JavaScript single-thread 'task', pack the callback invocation in setTimeout(...:

            let errorHandler = (err) => { ledOff(); reject(err);
                        setTimeout(callback, 100, err, { _: me, id: id }); },
                successHandler = () => { console.log('enroll success'); resolve();
                        setTimeout(callback, 100, undefined, { _: me, id: id })};
    

    This will allow other pending - and may be more pressing - 'tasks' to get a chance to do their thing. Applied throughout the whole application makes your application behave like a TSO - (processor) time sharing option - environment for each of the tasks, where you run less into timely-ness contentions (buffer overflow, stacking up to many and/or 'losing' events,...) - from the single core /360 times...

    For adding more to the module, such as getting the extra information on open, add a method .open(... following the same pattern as .enroll(... with callback, and adjust the successHandler accordingly.

    To make operations very robust, always begin with an open( and end with a close (to be added in both successHandlerand errorHandler. I do not know the finger print reader's sequencing control, but having a clear begin and end always helps - like demarcation of a transaction: begin and end with commit or rollback (a-la successHandler and errorHandler, respectively).

    Putting all in one single module is no difficult either. Just add the code into the first piece of code from @PaddeK.

    This conversation was great pleasure for me and makes me conclude: Old dog, new tricks? ...still works.

About

Avatar for allObjects @allObjects started