Some help: error in html !! Data arrives correctly to the datatable, but.. here: ... $(document).ready(function(){ var table = $('#table').DataTable({ Uncaught ReferenceError: $ is not defined So nothing is printed! Any ideas ???
There is no record locking when used as a method to view the data. Yes, it can be stale, but that timeframe can be controlled. If you are trying to interact with the data, then you can revert to using FileMaker via a card window, alternate layout or placing a lock on the record offscreen even. Most of these types of issues can be dealt with if you understand what is happening underneath the hood.
I need to create a script or in more general, a button on FMP 19, by which I manipulate my scanner, so that I can start a document scanning and be able to see this preview in PDF or other format in the container section provided for that. is there a way on FMP19 ??? thanks
Hi Mohammed. Yes, as with most of technology, someone has probably already had this itch and scratched it. There are a few resources I can think of that are likely paid. The serial plugin from Troi www.troi.com/products/serialplugin/ then you have the MBS plugin which will have some type of communication www.monkeybreadsoftware.com/filemaker/ and then there's 24usoftware.com who has done a lot of hardware integrations. If you want to go the free route and put some work in, then you can always pick a language of your choice, like Python, and use either the BaseElements free plugin or (if on a Mac) the bBox plugin. Whatever the choice, you will have to have some type of software that will bridge to the driver of the scanner and this will vary depending on the scanner. I hope this helps out.
Is there anything working within FM as advertised instead of third party plugin referrals or web viewer JS implementation requirements to get the job done?
There are many things that FileMaker alone can do. However, a lot of the “wiz bang” features with charting and a significant amount of what they call “events” are more possible within a web viewer in JavaScript than in native FileMaker. Of course, if the charts and features that FileMaker does offer natively does meet your needs then nothing is requiring the use of JavaScript and Web Viewers in order to take full advantage of FileMaker.
FM can handle authentication automatically, has the built in PDF writer and you can use other features out of the box on iOS like getting sensor data and geo cords from your phone, using iBeacons and reading NFC tags.
thanks! Well, portals are essential for data entry and FM SHOULD be first choice for data entry otherwise it is wrongly implemented. A frontend database is all about user interaction and to outsource this to the web viewer because of sluggishness is really a major flaw IMO.
I'm not advocating for replacing all portals, just those which are used heavily for data viewing. If you have a lot of field interaction then, yes, you'll stick with normal portals. It always comes down to how you plan to interact with the data.
@@filemakermagazine thanks for answering. The struggle I feel is the major discrepancy of FM slowness and JS flying speed interacting with data in Web Viewer. That the web is so much faster then anything natively in FM is a deal breaker!
Some help: error in html !! Data arrives correctly to the datatable, but.. here:
...
$(document).ready(function(){
var table = $('#table').DataTable({
Uncaught ReferenceError: $ is not defined
So nothing is printed!
Any ideas ???
Nice! What about Record Locking though?
There is no record locking when used as a method to view the data. Yes, it can be stale, but that timeframe can be controlled. If you are trying to interact with the data, then you can revert to using FileMaker via a card window, alternate layout or placing a lock on the record offscreen even. Most of these types of issues can be dealt with if you understand what is happening underneath the hood.
I need to create a script or in more general, a button on FMP 19, by which I manipulate my scanner, so that I can start a document scanning and be able to see this preview in PDF or other format in the container section provided for that.
is there a way on FMP19 ???
thanks
Hi Mohammed. Yes, as with most of technology, someone has probably already had this itch and scratched it. There are a few resources I can think of that are likely paid. The serial plugin from Troi www.troi.com/products/serialplugin/ then you have the MBS plugin which will have some type of communication www.monkeybreadsoftware.com/filemaker/ and then there's 24usoftware.com who has done a lot of hardware integrations. If you want to go the free route and put some work in, then you can always pick a language of your choice, like Python, and use either the BaseElements free plugin or (if on a Mac) the bBox plugin. Whatever the choice, you will have to have some type of software that will bridge to the driver of the scanner and this will vary depending on the scanner. I hope this helps out.
Is there anything working within FM as advertised instead of third party plugin referrals or web viewer JS implementation requirements to get the job done?
There are many things that FileMaker alone can do. However, a lot of the “wiz bang” features with charting and a significant amount of what they call “events” are more possible within a web viewer in JavaScript than in native FileMaker. Of course, if the charts and features that FileMaker does offer natively does meet your needs then nothing is requiring the use of JavaScript and Web Viewers in order to take full advantage of FileMaker.
Why using FM at all? NodeJS instead and no need for all the crazy conversions!
FM can handle authentication automatically, has the built in PDF writer and you can use other features out of the box on iOS like getting sensor data and geo cords from your phone, using iBeacons and reading NFC tags.
thanks! Well, portals are essential for data entry and FM SHOULD be first choice for data entry otherwise it is wrongly implemented. A frontend database is all about user interaction and to outsource this to the web viewer because of sluggishness is really a major flaw IMO.
I'm not advocating for replacing all portals, just those which are used heavily for data viewing. If you have a lot of field interaction then, yes, you'll stick with normal portals. It always comes down to how you plan to interact with the data.
@@filemakermagazine thanks for answering. The struggle I feel is the major discrepancy of FM slowness and JS flying speed interacting with data in Web Viewer. That the web is so much faster then anything natively in FM is a deal breaker!
Completely lost. About as clear as mud.