ReferenceError: $ is not defined

[Carlo Didier]

I have two apps with identical html part and identical button click function.

On the first, everything works fine, but on the second I get an error "ReferenceError: $ is not defined".
Visual Studio Code says "no problems have been detected".

I have commented out all the rest of the script, but the error remains, so it's not in that part.

Google wasn't helpful ...

Any ideas?

Just noticed that the first one doesn work anymore either, though I didn't modify it.
But I updated iMatch  before ...

I nnow noticed another error message that doesn't make sense at all (FFerror2.jpg). The paths are correct (nothing modified in the scripts or on the disk).

[thrinn]

With your index-problem.html, I get also reference errors, but not with respect to jQuery ($). All function definitions are commented out, so it is clear that the function calls in the "button action" part do not work anymore.
But I gather that is not really what you mean, is it?
If $ is not defined, there must be some problem loading the jQuery library.

[Carlo Didier]

If $ is not defined, there must be some problem loading the jQuery library.

That's what I found out by googling, but I have no clue why.
As I said, between the moment it worked and when it stopped working, the only change was the iMatch update from 11.4 to 12.2 ...
Nothing changed in the scripts, nothing in the paths, ...

[thrinn]

You index-ok works for me after creating the QUEUES categories in my test database.  No reference errors.
Could you specify where exactly you get an error?

[Carlo Didier]

Could you specify where exactly you get an error?

With Firefox. See the FFerror.jpg and FFerror2.jpg attached to my first post. Worked before.

I get a similar error in Edge.

Tried directly in iMatch now and there it still works (see attached screenshot)! Very strange!

[thrinn]

Ah, I see something like file:///system/jquery... in your FFerror2.jpg. This looks like you opened the index.html in the browser (File -> open) instead of requesting it from IMatch via an URL. Try to run the app from the App Manager.

[thrinn]

Opening an HTML file in the browser will not work. Use the URL the App manager generates when using "Open app in web browser".
http://127.0.0.1:50519/imatch/apps/info-app/index.html
If you use "File -> Open", the index.html will run locally in the browser, seeing you whole file system with different eyes and having no access to ressources only the web server (IMWS, in this case) knows about. The root of you file system will be C:\, for example, if index.html is located somewhere on your C: drive. And there is no jQuery under C:\system\.... That's why you get an error.

[Carlo Didier]

Opening an HTML file in the browser will not work. Use the URL the App manager generates when using "Open app in web browser".
http://127.0.0.1:50519/imatch/apps/info-app/index.html
If you use "File -> Open", the index.html will run locally in the browser, seeing you whole file system with different eyes and having no access to ressources only the web server (IMWS, in this case) knows about. The root of you file system will be C:\, for example, if index.html is located somewhere on your C: drive. And there is no jQuery under C:\system\.... That's why you get an error.

Aaaargh, only one week paused and I already forgot such stupid details ...
This whole new app stuff is just 100 times more complicated than the old scripting engine ... There's so many more factors that play a role in it.

Thanks, Thorsten!

[Mario]

Just remember to always 'load' the page from IMWS, not just open the plain HTML file from disk.
Tip: Use the "Open in web browser..." command from the App Manager the first time, then create a favorite/shortcut in your browser.

Loading a HTML file from disk instead of loading it from IMWS is vastly different. Loading a HTML file which then attempts to connect to a web server (IMatch) triggers all kinds of security features in your browser, code blocks, CORS and so on. Your browser does this to protect you.

This whole new app stuff is just 100 times more complicated than the old scripting engine ...

Not really. You just made a jump over 25 years of development, from the 90th BASIC to the 2015ish JavaScript.
You also get a lot better tools.

And as I said in the past, nobody forces you to use HTML or JavaScript. IMWS is programming language agnostic. You can use it from Visual Basic.NET, Python or even Windows PowerShell - all these languages are free and you can pick whatever suits you.

[Carlo Didier]

And as I said in the past, nobody forces you to use HTML or JavaScript. IMWS is programming language agnostic. You can use it from Visual Basic.NET, Python or even Windows PowerShell - all these languages are free and you can pick whatever suits you.

Yeah, but then it's not inside IMatch anymore ... and I still need to do web calls from those other languages.

I'm thinking about maybe creating my own little library of functions that wrap all the async calls into normal sequential functions using the async/await method.

Something like

Code Select Expand

            IMatch.get('v1/files',{
                idlist: IMatch.idlist.fileWindowSelection
            }).then(function(response) {

                arrFiles = response.files;

            },
            function(error){
                console.log("Getting seleted files didn't work ...");
                console.log(error);
            });
would then simply become

Code Select Expand

arrFiles = IMatch-GetFilesByIDList(IMatch.idlist.fileWindowSelection);
or something similar 

But once I have my 3-4 scripts I need, I may just stop there and save my time for the next big change.

And newer or modern doesn't always mean better, or at least not best adapted for a certain task.
I don't need the newest Tesla X with all it's high-tech gimmicks to get my bread from the baker when I can just walk there. Actually I'd be too lazy to take the car ... 

[thrinn]

I don't see why you would have to write your own wrapper library. You can use IMatch calls directly with await.

Code Select Expand

async function readSettings() {
  // Retrieve all entries from the IMatch settings store
  let vSettings = await IMatch.get('v1/data/list', {
    name: '.*'
  });

// DO SOMETHING WITH THE RESULT
}

Just do not forget that await  works only inside of async functions.

[Carlo Didier]

But that's still at least 6, complicated and difficult to read and understand, lines instead of one simple and clear line of code 

[thrinn]

But that's still at least 6, complicated and difficult to read and understand, lines instead of one simple and clear line of code

No. You did only show the assignment line, without a context. That's not a valid function or program. If you want to compare apples to apples, your line of code corresponds to

Code Select Expand

let vSettings = await IMatch.get('v1/data/list', { name: '.*' });
And you left out the function you would have to write...

[Carlo Didier]

But that's still at least 6, complicated and difficult to read and understand, lines instead of one simple and clear line of code

No. You did only show the assignment line, without a context. That's not a valid function or program. If you want to compare apples to apples, your line of code corresponds to

Code Select Expand

let vSettings = await IMatch.get('v1/data/list', { name: '.*' });
And you left out the function you would have to write...

I think you don't understand what I mean. My function would be "IMatch-GetFilesByIDList". The above would be hidden inside that function. To use it, the one line I mentioned would be enough to use it.

[Jingo]

To each his/her own... I find the new scripting language refreshing, open ended and powerful... and challenging!  I'm super excited to discover what I can do within IM using apps and JS... I much rather work with an industry fresh set of tools than an older static language... a quick google search gives me thousands of examples to pull from as well!  I suggest you just continue to give it time... I think you are making great progress already!

[Carlo Didier]

I think you are making great progress already!

Thanks! I hope I do. But it's a big pain for me. Because for what I need scripts, all the new stuff brings absolutely no advantage, only complexity and lack of functionality (event scripts!).
It's the fact that I have to learn lots of things I don't really need for what I want to do that puts me off. What was so simple to do in the old basic scripts is far, far more complex now. To me personally, it's only disadvantages.

[Mario]

If you would use BASIC (which you can) instead of JavaScript there would not be much new to learn.
Or maybe Windows Powershell. I think both languages are ot even capable of doing asynchronous processing so your major problem would solve itself.
Calling an IMatch endpoint would be an one liner. Many examples on the web.
There are at least 20+ programming languages to choose from.

Modern programming languages like Java, C#, JavaScript etc. embrace the concepts of parallel execution, asynchronous processing and promises because that is the bet way to deal with slow resources (like web services) and the ever-increasing numbers of processor cores. When BASIC was designed, the C64 was new 

[Carlo Didier]

Hey, I used a (friends') C64!  (does that show my age?)

I know I could use Powershell (I'm doing lots of Powershell at work), but as I mentioned elsewhere, that would seperate the scripts from IMatch, i.e. they would not run inside IMatch, which creates other potential complications.

You're right concerning slow resources, but I'm running my scripts locally inside IMatch. To each problem, you should use the best solution. Asynchronous web services for remote access and direct local function calls for local use. Actually, you can do something similar to promises in Powershell with the "as Job" option for many things. But it's an option, not a must. You can use it if you need it, but you don't have to if you don't need it.
Sometimes, like requesting an export of a mailbox from Exchange, you are forced to work asynchronously in Powershell. Guess what? That's the cases which cause the most problems and are most difficult to debug and to handle errors ... Some automated tasks I created at work would be much simpler and more reliable without that. After tens of thousands of lines scripted in various languages, you get to really hate some things ... 

[sinus]

Hey, I used a (friends') C64!  (does that show my age?)

64?

... sorry, could not resist. 

[Carlo Didier]

Hey, I used a (friends') C64!  (does that show my age?)

64?

... sorry, could not resist. 

Not yet! 
"Only" 52 ...

[sinus]

Hey, I used a (friends') C64!  (does that show my age?)

64?

... sorry, could not resist. 

Not yet! 
"Only" 52 ...

I thought, that your are not yet 64. 
It amused me only, what you wrote (does that show my age?).

Well, in this case you have still a lot of time to get 64 ... and you know, you must get 66 to start the life really (Udo Jürgens). 

[Jingo]

My first computer was a C64... a masterpiece ahead of its time... not to mention the Amiga which was WAAYY ahead of its time.  Too bad Commodore couldn't market ... and the Apple 2 took over.   Still have that C64 and tape drive someplace...along with my trusty ole  A-B TV switchbox!  thx for the memories...

[Carlo Didier]

Hehe, my first computer (that I really owned myself), apart from programmable pocket calculators like TI57, TI58C and HP-41CX, was an Apple II clone. That was the complete opposite of current Apple computers. It was an open system, fully documented. You even got manuals on how to repair it yourself! With instructions like "if there is no sound, check the voltage on pin 7 on IC #31 and replace it if it's not son-and-so" (all ICs were on sockets, not soldered!) Fun times!

[sinus]

Texas ...? ... with tape drive, cannot remember the name.
Then came Atari ST. 

[Mario]

My first computer was a Z1.

[Jingo]

Texas ...? ... with tape drive, cannot remember the name.
Then came Atari ST. 

Texas Instruments?  I had one of those that I took with me to college... a powerhouse... sold by Radio Shack... Tandy computer.  Was amazing since it had 16 colors instead of the typical 4!  AMAZING!

[Carlo Didier]

Ah, Tandy ... I learned my first BASIC on a TRS-80 in a Tandy shop. It was a demo machine that stood there and the shop keeper let me play on it for hours one afternoon each week.