User interface automation
I use Ninox on iPad and am trying to implement some user interface automation to create a switchboard of buttons for single click user access to different database activities. Generally this has been straightforward, but I have run into two problems that I can't resolve.
1. Trying to use the printRecord function gives the message "Function is not defined: printRecord(rid,string) at...", even though using openPrintLayout with exactly the same recordId and layoutName works perfectly. Is this a bug or is the printRecord function not implemented on the iPad version for some reason?
2. I want one of the buttons to open a form at a new record. I feel sure this must be possible using the openRecord(recordId) function, but cannot work out how to obtain the ID for a new record. This is probably me being obtuse, but if somebody could point me in the right direction, I would be very grateful.
Many thanks for your help,
for New Record creation use this code:
let myD := this;
let myP := (create ’Table Name');
...and for printing have you tried:
e.g. printRecord(this, "Print")
Thanks for coming to my rescue once again (ie https://ninoxdb.de/en/forum/technical-help-5ab8fe445fe2b42b7dd39ee7/single-page-formatted-print-of-all-records-in-a-table-5bbeea6025979e54233efaea?post&)!
Your solution for my New Record problem works perfectly of course (although without the first line, which appears unnecessary). As i thought, I was being slightly obtuse, having got hung up on following the syntax shown for the openRecord example in the manual, not realising I did not need to use the record function as I already had the required recordID from the create function.
With regard to the printRecord problem, yes - that is exactly what I have tried. For me, using the iPad version,
openPrintLayout(record('My Table Name', 1), "My Layout Name") works perfectly whilst
printRecord(record('My Table Name', 1), "My Layout Name") produces the 'Function is not defined' error. Have you successfully used the printRecord function and, if so, was this on the iPad version of Ninox?
Once again, many thanks for your help,
this works using the iPad (tested),
printRecord(this, "My Layout Name")
I have investigated a bit further and find that
printRecord(this, "My Layout Name") does indeed work as you say, but that
printRecord(record('My Table Name', 1), "My Layout Name"), which is the syntax specified in the manual, does not. Are you able to confirm this observation? If so, I can only assume it is a bug, although I cannot find any bug reporting facility on the Ninox website. Do you know how I go about it - another forum message?
In my case, where I have created a dummy table containing 1 record and no data fields (apart from Id obviously) to host the switchboard form, I cannot use the
this syntax as I am trying to print a different table from the one where the button and its code reside. So can you think of any other way to circumvent this problem? If not, I will use the
openPrintLayout function for now, which works and gets me very close to what I was trying to achieve, until the
printRecord function is fixed.
As ever, thanks for your help,
John, you are right! The function
printRecord(record('My Table Name', 1), "My Layout Name")
produces an error.
Maybe someone from the support puts this to Bugs category.
Thanks Nick - I'll report this on the Ideas & Suggestions section of the forum.
printRecord(this, "My Layout Name")
The code snippet in the manual seems to need an update.
Best regards, Alex
I am not sure what you are trying to say. We have already confirmed that the 'this' syntax does indeed work but that it is unsuitable in my case, which requires the syntax given in the manual (see posts #5 & #6 in this thread). Since you talk about changing the manual, are you suggesting that the manual code is wrong and that
printRecord(record('My Table Name', 1), "My Layout Name") is deliberately designed not to work? This seems most unlikely and I can see no reason for it, especially as
openPrintLayout(record('My Table Name', 1), "My Layout Name") works perfectly (see post #4). Therefore, I still consider this to be a bug which requires fixing.