Scripting in upcoming IMatch versions

[akirot]

Ceasing the current Visual Basic scripting implementation for an upcoming IMatch version has been discussed at some places. I understand why Mario is intending the introduction of new techniques and fully support his approach.
However, I use scripts around versioning (which extend IMatch's already rich functionality) and need them for the management of my images.
If they don't work on a new IMatch version this clearly would be an upgrade blocker.
I'm fine with learning new programming languages and techniques and using them for new scripts thus supporting future developments.
Mario, can you confirm existing scripts will continue to work (on an "as is" basis) on an upcoming IMatch version?
Will the new environment give access to the same methods etc. as the current implementation?

[Mario]

Mario, can you confirm existing scripts will continue to work (on an "as is" basis) on an upcoming IMatch version?

No. IMatch 6 will have no Basic scripting anymore.
I will not renew my license for this 3rd party toolkit anymore. Its old. Its expensive. The GUI support is not good.
IMatch versions prior to version 6 will receive no updates anymore and no support 6 months after IMatch is released. The Basic scripting engine in these products will continue to run, unless a Windows update or similar external change breaks the functionality.

For IMatch 6, all scripts will need to be rewritten using IMWS technology, in HTML and JavaScript.
I will do that for the few scripts I have provided (mostly import and export plug-ins) of course.

All other scripts I ship with IMatch are sample scripts which demonstrate how to the the object model etc.
These will be removed. IMatch 6 and IMatch WebServices use the same programming model and hence there will be one documentation and one sample script set for both.
I'm already working on that.

In addition, the embedded IMWS in IMatch will support a few additional programming interfaces. This includes functions to access the current file window ("get me all selected files"), support for reading and writing files, standard windows dialog boxes, IMatch dialog boxes and suchlike.

I try to keep it slim, though. There are not many people out there who write scripts for IMatch. There were more for IMatch 3, but IMatch 5 is so rich in functionality that not many scripts are needed. Many users out there don't even know about scripts at all. It makes no sense to spend weeks to develop something that will be used by 2 people out there.

Will the new environment give access to the same methods etc. as the current implementation?

In principle, yes. IMWS offers a rich set of "endpoints". To see what's offered, open the "Discover IMatch WebServices" from the IMatch WebViewer gear menu. If you don't have IMatch Anywhere, you can use the TRIAL edition or wait until IMatch 6 is released.

IMatch 6 and IMWS use the same programming tools and programming model. What works in IMWS will also work in IMatch. IMatch will just have some more methods which are available for scripts running "in" IMatch.

[DigPeter]

Mario - what sort of time scale for IM6?

[Mario]

Mario - what sort of time scale for IM6?

Sorry, but I don't mention fixed dates out of principle.
Too much can happen. I can meet a technical challenge that costs me a month to overcome...and all dates would be voided. Users would be disappointed or angry etc. No good.

I'm currently working on IMatch 6 most of my time. Things are going well. I aim at the 2nd. quarter 2017.

[DigPeter]

Thanks Mario - that is all I wanted.

[ubacher]

For me the scripts are what makes IM so powerful. And I seem to recall that you frequently turned down requests
saying that if this or that functionality is needed one should /could do it with a script. (Which I did.)
Now the problem is converting the scripts to javascript - But can I do this - can I run the old version (basic) and the new
version together? I need to use the old IM while the scripts are still not converted and the new one for the conversion.
I see a logistics problem. Or will you provide a V5 which has both scripting engines for the purpose of converting?

Since I don't know Javascript I will need a lot of examples to get me going and I will need time to learn so I can do the conversions.

[Mario]

I will remove the scripting engine from IMatch 6 - actually it's mostly gone already. Makes things quicker and removes a lot of code.

I doubt that you can run both IMatch 6 and 5 on the same system, because not only is the IMatch 6 database format 'newer' (to incorporate the changes I make for IMatch 6) but also the versions would need to share settings, plug-ins, configuration files, settings database, .... Way too hard to keep all this synchronized.

Better prepare to have a second PC to run the 5.5* version of IMatch and one on which you run the IMatch 6 version.
I don't know how many scripts you have created or what these do so I cannot comment on that.

You can already start programming now, using IMatch WebServices to access your database contents.

All you need is a text editor (e.g. Notepad++ or the free Microsoft Visual Studio Code https://code.visualstudio.com/Download).
Your browser (recommended: Chrome or Firefox) have built-in developer tools <F12> key. They show you what data you send, what data comes back from IMWS. You can set breakpoints in your code, just like in the Basic editor in IMatch. Just a lot faster and easier.

The endpoints (programming interfaces) of IMatch WebServices are documented directly in IMatch WebViewer. Gear menu > Discover IMatch WebViewer. The code examples work with your live database and return real data.

More documentation and sample code for using IMatch via IMWS is in the making. I will publish things in the Learning Center when I finish something.

If you have never used JavaScript, start here:

http://www.w3schools.com/js/

[DigPeter]

@John Zeman

I hope you are following this, John.  I find your script "The Ultimate Image Description Writer" very useful.  Will you be converting it to run with javascript?

[JohnZeman]

Peter if I was a few years younger I would, but I'm getting to the age now where learning something new is far easier for me to say than it is for me to do.  So going by what I'm reading here I'll probably stay with version 5.

It pains me to say that because I really love IMatch but version 5 is doing everything I want IMatch to do and I have to keep my own reality in mind.

[Mario]

Maybe you can send me your script so I can have a look at what it does?
Does it things the Metadata Panel or the Keywords Panel cannot do?

IMWS is currently read-only but naturally I will add features to update the database (metadata, categories, ...) over time. This will allow users to update metadata in their browser and of course also in IMatch scripts.

I know already that I can easily port the CSV import, Import Metadata into Attributes, HTML Report, KML Esport and maybe I will even do the Juicebox export.

[JohnZeman]

Mario that script is listed in the Script Gallery here in the forum, it's called The Ultimate Caption Writer.  Below is a copy and paste of what it can do.

• Edit the current caption (description).
• Actively monitor and show the total size of the current caption as you type.
• Copy the current caption to the clipboard.
• Replace the current caption with the text on the Windows clipboard.
• Compares the captions of the selected images to see if they are identical.
• Find specific text in the captions of the selected images.
• Replace specific text in the captions of the selected images.
• Append text to the end of existing captions of the selected images (even if the existing captions are different).
• Pre-pend text to the beginning of existing captions of the selected images (even if the existing captions are different).

[Mario]

I see. Some of these things can of your be done in the Metadata Panel (1-5).

The find text in caption, replace, append and preprend are specialties. I don't see a frequent use for those but I understand that having this may be helpful for some users in some situations. I don't recall a feature request for this, but a "more advanced" editor (e.g. in a popup) for the Metadata Panel would not be so hard to do.

And of course this is also an ideal beginner example for working with IMWS. As soon as I have the "updating data" features implemented. And it would look real nice, because of the HTML we can use to create the user interface for it.

[DigPeter]

I see. Some of these things can of your be done in the Metadata Panel (1-5).

The find text in caption, replace, append and preprend are specialties. I don't see a frequent use for those but I understand that having this may be helpful for some users in some situations. I don't recall a feature request for this, but a "more advanced" editor (e.g. in a popup) for the Metadata Panel would not be so hard to do.

John produced this script early in the life of !M5, so filled a need of some people, who therefore did not need to request it in the Forum. 

The metadata panel can be used to change Descriptions of many files simultaneously when they are all the same.   I find John's script useful particularly for amending several files with different descriptions simultaneously.  The last 3 of John's list are particularly helpful in this respect.

I would welcome such a script to be built into future versions of IMatch.

[Mario]

I would welcome such a script to be built into future versions of IMatch.

I recommend adding a feature request then.

[Aubrey]

If you have never used JavaScript, start here:

http://www.w3schools.com/js/

Neat. Time to learn a new computing language, I've started on the tutorial this afternoon.

[DigPeter]

I would welcome such a script to be built into future versions of IMatch.

I recommend adding a feature request then.

Will do, but I cannot find the IM Feature Request board - only for IMA & IMW.

[Mario]

I would welcome such a script to be built into future versions of IMatch.

I recommend adding a feature request then.

Will do, but I cannot find the IM Feature Request board - only for IMA & IMW.

The IMatch feature request board is the one.

[Ferdinand]

So going by what I'm reading here I'll probably stay with version 5.

+1

[akirot]

These are some of the methods I use:
Application.Database.SelectFoldersDialog(...)
QueryFiles (...)
RemoveFile(...)
AddFile(...)
Database.CreateManualVersion(...)
Database.DeleteManualVersion(...)

I consider the latter ones as core functionality.
If this core functionality gets lost with a next version of IMatch I can't and won't upgrade.
Visual Basic itself might be abandoned but please show an upgrade path.
Personally I don't need IMA.

Slightly off topic:
I don't have real performance issues (with currently about 100.000 images and many many categories - can't count them right now because I'm not at my desk).

The map panel still has the "old" glitch of sometimes not showing tiles because of "possible server overload" - I never experience this with geosetter (which is my fallback for these situations). One doesn't need web access to the DB to fix this.
The viewer still is outperformed by the fastpictureviewer  (unfortunately it can't be integrated closely because it works directorywise). This will not improve with webaccess.

[Jingo]

And of course this is also an ideal beginner example for working with IMWS.

Yes.. examples on how to currently interact with the scripting features would be nice.. I've read the documentation that displays all the "methods" for interacting with the IMatchviewer.. but still can't figure out how to setup an HTML file with the necessary JS/css files to interact with the database and display data.

For example - lets say I have marked 10 images as Favorites in IMA via the "heart" icon.... now, I want to write a script that locates these items and creates a filename list with paths... don't see how that's possible.  Also, is there a ways to add our own "panels" to IMA via scripting as we can do now with the Funtoy? 

Just trying to figure out how scripting currently works and what kind of things can we do with it.  thx!

[Mario]

The viewer still is outperformed by the fastpictureviewer

Interesting. I measure the opposite. IMatch uses hardware-based DirectX rendering. FPV cannot be faster. But IMatch does a lot of stuff FPV does not, including metadata display, collections and stuff. If you need the maximum speed, turn of the stuff that holds back IMatch.

The map panel still has the "old" glitch of sometimes not showing tiles because of "possible server overload" -

I even get that sometimes from Germany when I directly work with GeoNames.org and OpenStreetMap. But since you are using GeoSetter you have an alternative for this situation and don't need IMatch. Or get yourself a paid account and support the OpenStreetMap and GeoNames community projects. This gives you access to the faster servers and you most likely will never face a timeout again.

If this core functionality gets lost with a next version of IMatch I can't and won't upgrade.

You don't need to upgrade. IMatch is no subscription. It won't stop working when you don't pay. I will no longer support it of course and the Basic scripting may break with a Windows update if it is not maintained anymore.

The few scripting methods you mention are low-end stuff. I will of course provide access to relations (IMWS already does the full functionality, but only read-only) but it may not be in the first version of the API. I will concentrate on standard stuff first. Not many users will need to create or remote manual versions in the first fee weeks.

[Mario]

Yes.. examples on how to currently interact with the scripting features would be nice..

Of course. As I wrote yesterday I'm already working on the IMatch Developer Center web site. And samples. And tutorials.
IMWS is already documented.

Just start with a JavaScript tutorial that explains how to use a web service.
I mentioned a good learning web site yesterday.

Accessing a web service takes 5 lines of JavaScript. Once you have get that to work, pick one of the methods of IMWS, e.g. the /info endpoint which returns information about IMWS and the database.

I used that for the first example script in my tutorial (not yet accessible for the pubic).

[Mario]

The IMatch Anywhere Developer Center has opened today.

Check it out for tutorials, resources and some initial sample scripts.

[Jingo]

Woot!  That was fast... thx Mario... off to play!!

[hro]

Well Mario, I shouldn't be surprised that you keep surprising us. The Developer Centre is great and could become a very valuable resource.
When do you have a break ? 

[Mario]

Well Mario, I shouldn't be surprised that you keep surprising us. The Developer Centre is great and could become a very valuable resource.
When do you have a break ? 

This was a work in progress for some time.
I will add more examples as I write them. The examples will also be test cases for me, during the development of the scripting system for IMatch 6.

[Ferdinand]

For IMatch 6, all scripts will need to be rewritten using IMWS technology, in HTML and JavaScript.

Under the existing basic scripting engine in IMatch 5 it is possible to trigger external applications, e.g. Microsoft Word & Adobe Photoshop, using the COM interface and control those applications.  Will this be possible using the technology available in IMatch 6?

[Mario]

Hi, Ferdinand  Long time no read!

No, sorry. No COM support or controlling external applications. This is so very rarely used, it makes no sense to hold onto WinWrap Basic just for that.

It is so much easier to use PowerShell or one of the other free programming languages for Windows to use COM or OLE to control applications.
And if you somehow need to transfer data from IMatch, you can access IMWS from a PowerShell script or most other programming languages.

If this really becomes a problem I may think about support for spawning an external process from a script running inside IMatch, e.g. to run an external application or a PowerShell script. We'll see if there is enough demand for such a thing.

[Ferdinand]

No, sorry. No COM support or controlling external applications. This is so very rarely used, it makes no sense to hold onto WinWrap Basic just for that.

This is a blocker for me.   That is in addition to a number of workflow scripts that I use and which I no longer have to time to migrate (again).

It is so much easier to use PowerShell or one of the other free programming languages for Windows to use COM or OLE to control applications.
And if you somehow need to transfer data from IMatch, you can access IMWS from a PowerShell script or most other programming languages.

Too much work to redo it all to work like this.  Life is too short.

If this really becomes a problem I may think about support for spawning an external process from a script running inside IMatch, e.g. to run an external application or a PowerShell script. We'll see if there is enough demand for such a thing.

I will check in from time to time to see if you choose this option, although it may still not meet my needs.  The number of forum users who use the COM interface, and my script that relies on it, is probably small, but I'd have thought that there would be institutional and corporate users who would use it.  I bought IMatch 3.4 over 12 years ago for the scripting engine, and most likely when it goes then so .....

[sinus]

Mario, Ferdinand,
I don not understand.

I want simply take some datas from Images in IMatch, like Attributes or metadata, and put them into an external program, like Word.

In WinWrap this is quite easy possible.

Is this not more possible in the future with JavaScript?

[Mario]

Is this not more possible in the future with JavaScript?

You can of course export data from IMatch into external applications.
What Ferdinand is talking about is controlling applications like Word or Photoshop directly from inside IMatch. This will no longer be possible.

I think remember you use(ed) a "Word Contact" script where you used OLE automation from IMatch Basic to control Word directly. This will no longer be possible. But I recal that you abandoned that script and now use Design & Print to create contact sheets and PDF files?

Frankly, I'm very happy to get rid of the OLE/COM automation stuff in IMatch. It was unreliable and unstable and cause a lot of PITA on my part. Ripping out the Basic scripting will deduce complexity in IMatch a lot, and speed certain things up considerably.

Losing the ability to control Office or maybe Photoshop directly from IMatch will affect only very, very few users and that's a price I'm willing to pay. We gain so much from IMatch WebServices and the modern scripting environment.

And it's easy to automate Word from PowerShell scripts anyway. And if a user really needs to automate PS or Word and "use" IMatch data in that process, he can do so easily by writing a PowerShell or Visual Basic and C# script and retrieve data from IMatch using IMWS.

[sinus]

Is this not more possible in the future with JavaScript?

You can of course export data from IMatch into external applications.
What Ferdinand is talking about is controlling applications like Word or Photoshop directly from inside IMatch. This will no longer be possible.

I think remember you use(ed) a "Word Contact" script where you used OLE automation from IMatch Basic to control Word directly. This will no longer be possible. But I recal that you abandoned that script and now use Design & Print to create contact sheets and PDF files?

Ah, I see, phew, you can remember a lot, asthonishing for me. 

Yep, WordContact is not more a problem for me, you are correct, I use successfully Design & Print (what is a very good tool).

What I have some time, is a script, what does takes some attributres-values and put them into Word.

I have for example 3 files.
In each file are some different numbers, say 100, 122.50 and 222.75.
This is, roughly said, the amount for a bill.

The script takes not these numbers out of the attributes and put them into Word and does create a nice bill (inlcuding adress, date and so on).

This script is very good for me, I see in IMatch, how much money an event gave and it is easy to create a bill.

I think, when I see it now correct, this is not more possible with JS.

[Mario]

but I'd have thought that there would be institutional and corporate users who would use it.

Not really, no. I actually expect more institutional/corporate users to start accessing IMatch data now that IMWS is available. I've worked with a customer in Norway who integrated IMatch data and imagery into his Wordpress site using IMWS. The entire project was done in about one day, with only one programmer involved. They now pull IMatch contents into Wordpress using some PHP code.

Another early-bird user from the UK is currently finishing an app based on the free Electron. Eltron allows you to create 'real' applications using JavaScript. It use the Chrome browser engine and Node.js internally. This means you write the user interface with JavaScript and HTML, but you can also access the file system, databases and of course web services like IMWS.

The end product is a real executable, with an installer and all that.
And it runs on Windows, Mac and Linux!
Very fascinating!

Thanks to IMWS I could create a small application which connects to IMWS, allows me to search the database and to display the resulting files as images in a couple of hours. Could very well evolve to a standalone slide show app or something...

[Mario]

This script is very good for me, I see in IMatch, how much money an event gave and it is easy to create a bill.
I think, when I see it now correct, this is not more possible with JS.

Not if your script works by using OLE/COM to "control" Word directly.

But of course you could just export a CSV file with the data and then use this as input for Word. Word has functions to import CSV files to to print bills using the "Serienbrieffunktion". This should even be easier than writing a custom script just to transfer a couple of sums from IMatch.

Exporting a CSV file is already available in IMatch, using the powerful Text export module. You can export IMatch data, metadata and Attributes with many options.

I will provide methods to read/write files for JavaScripts running in IMatch of course. This is a mandatory feature because I will rewrite all Import & Export modules currently using Basic in JavaScript. I'm really looking forward to this, because I can create much better user interfaces in no time with HTML and CSS.

[Mario]

I've just updated the IMatch Anywhere Developer Center and added a new demo script.

This script shows how to authenticate a user. Once this is done, we can use all IMWS features from scripts.

The new demo has two parts. The second part shows how to use a form to get a user name and password. And it uses a different theme to make the script look like IMatch WebViiewer:

[sinus]

This script is very good for me, I see in IMatch, how much money an event gave and it is easy to create a bill.
I think, when I see it now correct, this is not more possible with JS.

Not if your script works by using OLE/COM to "control" Word directly.

But of course you could just export a CSV file with the data and then use this as input for Word. Word has functions to import CSV files to to print bills using the "Serienbrieffunktion". This should even be easier than writing a custom script just to transfer a couple of sums from IMatch.

Exporting a CSV file is already available in IMatch, using the powerful Text export module. You can export IMatch data, metadata and Attributes with many options.

I will provide methods to read/write files for JavaScripts running in IMatch of course. This is a mandatory feature because I will rewrite all Import & Export modules currently using Basic in JavaScript. I'm really looking forward to this, because I can create much better user interfaces in no time with HTML and CSS.

Thanks Mario,
This gives me some new courage.
Very appreciated!

[Mario]

To print bills, nicely formatted, using Word is quite easy do to. Many tutorials on the web for that, also for using a CVS file with data (exported from IMatch) as the source for the bills.

[ben]

Interesting to see what's going to happen with iMatch 6.
I am looking forward to a big new version step.

On the other hand i have a few (quite) long scripts that i frequently use.
Actually the scripting capability was the most important feature when i switched to iMatch.
I cannot believe, only few people use it??!!   

Visual Basic indeed is veeery old. And i think it's a good idea to introduce new technology.
But, don't say "that's the way it is; use it or leave it".
Come on, not upgrading to IM6 someday is not really an option.

Please make the switch as easy as possible to everyone.
It should definitely be possible to run iMatch 5 and iMatch 6 besides each other.
I am not going to buy another computer, just to do the transition to IM6.
To compromise, it would be enough to not share the settings and databases. But installing and running them parallel should be possible.

Personally, i use the functions below. Will they be available?

Code Select Expand


Application.SelectFolderDialog()
Application.GetSystemTempFolder()
Application.CreateZIP()
Application.CreateFolder()
Application.GetKeyState()

Set objShell = CreateObject("WScript.Shell")
objShell.Run(cmd)

Set objNetwork = CreateObject("WScript.Network")
objNetwork.MapNetworkDrive
objNetwork.RemoveNetworkDrive

Set objFSO = CreateObject("Scripting.FileSystemObject")
objFile = objFSO.GetFile()
objFile.Copy()
objFile.Delete()


Uff, while scrolling through my scripts (one over 1400 lines) i am definitely not eager to rewrite them.

Ben

[Mario]

Allowing to run IMatch 6 and IMatch 5.x together on the same system would require:

Maintaining different set of settings, options, storage databases, settings databases.
This will be a lot of work on my part, confusing and potentially dangerous for users if they mess up. It's usually better to don't give users chances to mess things up.

And of course the databases are not compatible. IMatch 6 stores "more stuff" in the database (due to the video support, improved categories, etc.) IMatch 6 automatically migrates IMatch databases when they are first opened. This is a seamless process and users don't even notice (IMatch does that often when new features are introduced). But once this is done, you cannot open the database with an older version of IMatch - instead you will see a warning.

Some of the functions you mention will be available, but others will not.
GetKeyState has no meaning in a browser. There are functions in JavaScript which tell you the key state "in the browser" but the App Panel of course has no access to Windows key states. Not interesting.

There is no support for COM (WScript or whatnot). This is all soo old now...

If you need this, consider writing an external application or a PowerShell script.
You can access the IMatch database contents from external scripts and applications easily using IMWS. This was never possible before, mind!


I will remove Basic Scripting from IMatch as soon as my distribution license for WinWrap Basic runs out. This will be June or July I think. After that point, IMatch will no longer include Basic scripting. Any good riddance I say.

I understand that a few user may be negatively affected by that. But most users won't.
Believe it or not, most users have never written a script. Or even know that this is possible. This was different 10 years ago.

The distribution license for WinWrap costs more per year than my computer, a professional MSDN subscription and all other software and licenses I need for IMatch together. Upgrading to the latest version of WinWrap (with slightly better UI etc.) will cost three times as much - plus higher annual royalties. No way, sorry.

JavaScript gives us powerful tools, super-cool user interfaces. We can write a script once and run it "in" IMatch as well as in any web browser. The script will work with the IMatch database on your local PC but also will work (with IMWS) when your database is running on a PC in your basement or on a server on the other side of the planet.

All technology that will become important in DAM over the next years is based on or linked to web technologies currently available or being developed. IMatch will embrace that thanks to the technologies I have developed for IMatch Anywhere.

Yesterday I've made a few tests with some "A.I." web services which do image analysis.
My little test application (written using JavaScript and running in a browser) sends thumbnails from images in my sample sets to the service . The service responds with info like:

+ Number of persons in the image
+ Gender, age and mood of these persons
+ Objects in the image (boat, car, bicycle, building, street, ...)
+ If the image shows a well-known place or building, I even get the name and address of the building!
+ A description of the image (busy street scene, car race, boat on a river, ...)
+ Suggested keywords for the image
+ Detected License plate numbers
+ Runner numbers (very cool for photographers shooting marathons or similar)
+ If the image shows text of sorts, the extracted text  (street names, billboards, ...)
...

Naturally, the system is not always right. Some information may be wrong. People are still better at this than machines. BUT...

...consider this technology included in IMatch. Automatic descriptions, tagging, categorization of files.
You only need to check and correct where it is wrong.

A massive help for people who need to describe or tag many images. Either by starting with DAM or because they shot so many images in a day (sport, wedding, school, event, ...)

And, you don't need to hand over your files to some company and store it in their "cloud". You still keep control over your files.

[ubacher]

I fully agree to replace vbasic but converting all the scripts which I have been using, many since IM3, will take time.

We can already use javascript in the app panel. Could you not add the javascript interface library to version 5 so we can
start developing?
And: can we have instructions as to the logistics of programing with javascript... (Where to code (a browser I understand?), how to test....
I have not looked at IMAW so its likely that some of these instructions are there.

IM5 can perform many actions without needing a script. However, if I want to perform a series of steps with just one click I still need
to use a script..

[Mario]

The IMatch Anywhere Developer Center has links to free tools for developing with HTML and JavaScript. It has links to good on-line tutorials for JavaScript and HTML. This should get you started quickly. There are so many tutorials out there, even videos on YouTube if you prefer that - which is probably one of the reason that JavaScript becomes so huge and is now used from the tiniest little computers to big. big web servers.

The Developer Center also has several example scripts which show the basic steps for using IMWS from JavaScript. I will add more examples over the next months as soon as I finish them.
These scripts work with IMWS now, and will also work "in" IMatch 6 once it is out.

The documentation of all endpoints (methods) provided by IMWS is "built-in", so to speak. You can see it in the IMatch WebViewer when you click on the Gear icon and then select "Discover IMatch WebServices2". 

[ben]

So, i still don't get the whole picture.
Are the following statements correct?


1) Acccessing iMatch functions (=endpoints?) over the web or network is done via IMWS, which is part of iMatch Anywhere.
iMatch 6 will contain the same core functionalities, but doesn't use the same name (IMWS).


2) That means,
I can run a javascript script through my webbrowser -> IMWS
An i can run the same javascript script inside IM6.


3) Besides that, IM6 will contain some extra functions (endpoints), e.g. to access files on my harddrive.


4) COM will not be supported anymore in IM6.
If i want to access "external functions", i need to write a script outside of IM6. -> e.g. controlling word, WScript(), ..
So, e.g. a powershell script can access these "external functions" and i can use the IMWS to access iMatch database functions.
A powershell script cannot access IM6 functions, only through IMWS -> e.g. "get_files_from_filewindow()", or "get_categories_of_current_file()"
That means, whenever i need to access iMatch database functions from the powershell, i need iMatch Anywhere, as well (not only IM6).


5) Calling a subprocess (exec()) from within IM6 is not possible yet.


Ben

[Panther]

I doubt that you can run both IMatch 6 and 5 on the same system, because not only is the IMatch 6 database format 'newer' (to incorporate the changes I make for IMatch 6) but also the versions would need to share settings, plug-ins, configuration files, settings database, .... Way too hard to keep all this synchronized.

I must be missing something simple here, but I really don't understand why it shouldn't/couldn't be possible to have two separate installs of iMatch co-exist on the same computer.

Let's say I have my database and iMatch version 5.7.2 currently on my PC.  I'd like to maybe get a later version of iMatch (say, version 6) and play around with it to see if it's something I really want to upgrade to, but I want to keep using my old version 5.7.2 and that database while I'm playing around with deciding about version 6.  It really seems like overkill to have to buy/borrow a whole new computer to be able to do that.

Why do those two copies/versions have to share one set of anything or synchronize settings and things between the two versions, i.e., why couldn't the two versions be isolated/independent of each other?  Couldn't there be a step during the installation process for the new version that asks whether the user wants to update an existing version or install a new, clean copy of the new version, and then complete the installation accordingly?  If the user chooses to update an existing, older version of iMatch, presumably the installer would do what apparently it does now, wiping out the older version and leaving the user with only the newer version of iMatch on their PC.  But if the user chooses to do a clean install, it would create a separate, standalone copy of the new version of iMatch (presumably like it does now if the user doesn't have an older version of iMatch on their PC already).  Is it really necessary for every version of iMatch to put its settings or whatever in exactly the same place - couldn't it be told to put them in some location specified by the user or at least a location that is specific to the version being installed?

I understand why you wouldn't be able to use both the old and the new version of iMatch on the same copy of the same database, so once you open any particular copy of a database with the newer version there's no way to also open it with the old version.  And while it might be nice if both copies could be run at the same time, that could also get pretty confusing and I would understand if maybe that wasn't possible and you had to run either one or the other but not both at any given time.   But if I'm willing to maintain separate copies of my database (and presumably separate copies of my image files that are in the database, if necessary), I don't really understand why the new iMatch version has to search and destroy any previous version and can't be allowed to peacefully co-exist with the old version if the user tells it to do so.  Probably nothing else I have installed on this PC is quite as complex as iMatch, but I have several games and other programs that appear to have been designed to store whatever settings or other things they need locally within their own separate installation folder structure, and they don't seem to know or care whether I have several separate copies of them installed on the same PC and don't seem to need to share things between the various copies.

(You may note that I used version 5.7.2 in my example above - one of the reasons I'm still back on 5.7.2 and haven't updated to 5.8.2 yet is I generally don't like to risk messing with the old version that is working for me just fine unless/until I've had a chance to play around with the new version to make sure it works OK for my purposes, and having to deal with a second computer to do that tends to drag out the process.)

[ubacher]

I understand I won't be able to run V5 and V6 on the same machine.

What about IMAW and V5?
(Since I have no need for IMAW I did not follow its development and I am not aware
how it works together with existing versions. Isn't it just an add-on?)

I only seem to have to install IMAW so that I can develop replacement scripts in advance to V6 coming out.

[Mario]

So, i still don't get the whole picture.
Are the following statements correct?

1-3: Correct.

4: Partially correct.
JavaScript has no notion of COM or other proprietary Microsoft technologies.

The embedded IMWS inside IMatch is not accessible from scripts running outside of IMatch. I will probably setup something that allows this, with restrictions. We need this to use debugging tools in browsers. The App Panel has no built-in debugger (Windows restriction, not mine). But I need to prevent not-so-honest users from abusing IMatch as a cheaper replacement for IMWS by running IMatch and a separate web server on the same machine.

So, probably you won't be able to access IMWS functionality from external scripts when you don't have IMWS.

5. Correct. JavaScript cannot run external processes (thankfully!).

If there is demand I could probably implement this in IMWS and give you an endpoint. Or I implement it as an extension for the App Panel browser (IMatch 5 uses that to make the IMatch scripting API available in the App panel). It's crude and I' happy to get rid of it now that IMWS is there. But I will implement some features like system dialogs (File Browser etc.) that way, and implementing a method than can run launch an external process can be added as well. But that is not COM, no connection can be made to the external app.

That is so rarely used it would be a waste of time. Please understand that not many users use scripting. And of those who do, not many write scripts. And of those who write scripts, not many would ever need something like the Windows Scripting host. Or automate Office applications or Photoshop. I could spend two or three months developing support for that, and then learn that you and Ferdinand are the only users who ever used this...

AFAIK Node.js can and so can Electron. Electron uses Node.js internally. Both "frameworks" allow you to write apps in JavaScript (and to access IMWS and other web services) and give you access to the file system etc. And they work cross-platform.

[Mario]

I must be missing something simple here, but I really don't understand why it shouldn't/couldn't be possible to have two separate installs of iMatch co-exist on the same computer.

1. IMatch 5 and 6 use different database formats. IMatch can automatically upgrade databases (5 to 6) but it cannot downgrade databases. So once your database has been opened with IMatch 6, you cannot longer open it in IMatch 5. This can be solved, of course, by using a copy of your database with IMatch 6.

2. IMatch 6 uses different settings. Again, IMatch can always upgrade settings databases, registry settings etc. But it cannot downgrade them. Your IMatch 5 version may not be able to read the settings anymore.

3. IMatch 6 (may) use different (improved) formats for Batch Processor Presets, Category Schema, Thesaurus, File Window Layouts, Sort Profiles and more.

Of course I can spend time and adding extra code which somehow splits IMatch 6 settings databases and presets from older versions. Install into a different folder, copy and rename the settings database for IMatch 6 and all that. I will think about what would be involved, how much work it will cost me and if it is worth it.

[Mario]

I understand I won't be able to run V5 and V6 on the same machine.

That's still on the slab. IMatch 6 is a full upgrade and I may decide to duplicate and separate all settings. Then you can run both versions side-by-side (with separate databases!).
But that would  require several extra weeks of development so I'm still looking into this.

What about IMAW and V5?
(Since I have no need for IMAW I did not follow its development and I am not aware
how it works together with existing versions. Isn't it just an add-on?)

It's an add-on in the sense that you currently use IMatch to create and manage your database. And when you have IMatch Anywhere you can access the database remotely, from any device and operating system.

I only seem to have to install IMAW so that I can develop replacement scripts in advance to V6 coming out.

Yes. But you can also just wait until IMatch 6 comes out.  No need to rush things.
Or use the IMatch Anywhere TRIAL edition when you can do whatever you want to do in less than 30 days (until the TRIAL edition expires).

[Panther]

Of course I can spend time and adding extra code which somehow splits IMatch 6 settings databases and presets from older versions. Install into a different folder, copy and rename the settings database for IMatch 6 and all that. I will think about what would be involved, how much work it will cost me and if it is worth it.

Things always seem simpler to me than they turn out to be, so I'll certainly understand if this turns out to be too complicated/more trouble than it's worth, but it sure would help people like me to upgrade to new versions with less angst, so I appreciate your willingness to at least look into it.  Thanks!

[Mario]

Using the same database with both IMatch 5x and IMatch6x is out of question already. If you want to run both versions side-by-side you need to keep separate databases. I think this is understandable.

I usually "upgrade" the folder holding settings and resources for each major upgrade (which is why it is named C:\ProgramData\photools.com\IMatch5 instead of just "IMatch") and this makes it possible to keep the settings separate. I just need to get logic in place to copy over all the existing settings in the installer or in IMatch 6 itself during the first launch and all that. I did this in the past but of course there is now a lot more stuff around. We'll see.

Note: IMatch 6 is an evolutionary upgrade, not a hard break like the migration from IMatch 3 to 5 in 2014.
IMatch 5 to 6 will be a very smooth transition - except for a small number of users who have written their own scripts.

I depend on users upgrading. My costs are always the same, whether or not you upgrade. And when you don't upgrade, I don't make money and cannot pay for software, licenses, royalties, support and dev time, servers, all the time I spend writing documentations, samples, making videos, ...

[DigPeter]

..... except for a small number of users who have written their own scripts.

I do not write scripts, but certainly use some that others have kindly shared.