I'm trying to write a script that connects with a VBA/COM API to get the status of a connected phone. I've been looking up and down this forum for tips or other user's experiences, but I can't seem to find anything (even remotely) similar. It shouldn't be so hard to do, however.
Software I'm trying to connect to
I'm trying to integrate CallCenter by using their API, which is documented over here : JustRemotePhone API Reference
Things I've tried
I've tried using ObjCreate but I don't get any result, it always returns the same (negative) error.
#Version 1 tried ObjCreate("JustRemotePhone.RemotePhoneService") #Version 2 tried ObjCreate("JustRemotePhoneCOM.RemotePhoneService") #Version 3 tried ObjCreate("JustRemotePhoneCOM.RemotePhoneService.Application") None of the three versions I tried seem to deliver any result other than a negative error value which basically says that the given class is not valid.
I am starting to get the hang of AutoIt by now, but unmanaged programming languages and object-oriented stuff is still quite a grey zone for me. If anyone could help me 'talk' to this application, I'd be immensely grateful!
Thanks in advance and kind regards from Belgium!
Hello everyone, I am wondering if and how it is possible to connect my AutoIt script to a different email in my outlook. I have two different accounts when I open outlook. The first which my script always connects to is my own email while the second is a group email account. How or can I make the script connect to the second one and access its inbox instead of mine? This is all work related so no funny business here.
Global $oOutlook = _OL_Open() ; Store all the Unread emails into an array Global $aItems = _OL_ItemFind($oOutlook, "*\Outlook-UDF-Test", $olMail, _ "[UnRead]=True", "Subject", "Maintenance Request from Eagle's Nest", "EntryID,Subject", "", 1) ; Display the array of unRead emails If IsArray($aItems) Then ;_ArrayDisplay($aItems, "OutlookEX UDF: _OL_ItemFind - Unread mails") Else MsgBox(48, "OutlookEX UDF: _OL_ItemFind Example Script", _ "Could not find an unread mail. @error = " & @error & ", @extended: " & @extended) EndIf ; Get the number of unread emails Global $numberOfUnRead = UBound($aItems, $UBOUND_ROWS) - 1 ;MsgBox("", "Number of Unread emails", $numberOfUnRead) ConsoleWrite("Number of unread emails: " & $numberOfUnRead & @CRLF) I might be missing some code in the post but my code works It's just so long I don't want to post all 2300+ lines.
Thank you for the help I greatly appreciate this community.
Hello everyone, it has been a while since I have been involved in a serious AutoIt-related project discussion in the forums here, so it feels good to be back at it
First a little backstory, a few months back (or a year ago) I made the switch to Linux from Windows... there were several reasons as to why I was motivated to do it, but the main things was Windows 10 was getting out of hand, it didn't offer enough freedom out of the box (restrictive settings, greedy defaults etc.) and had several issues with all kinds of software, many of them mysteriously hard to fix.
I did have Linux installed as my secondary operating system for few years at that point and I began to see me regularly use it more than Windows, so one day I went ahead and said "fork it", I have stuck to Linux from that point on as my primary operating system.
Windows is still installed in my computer and I also have a virtual machine with the latest version of Windows 10 on it, primarily because I still use Windows to write software using AutoIt as part of my job (freelance).
I was pretty sad about the fact that I could no longer use AutoIt to make stuff for myself (since it doesn't run on Linux), I missed sharing code with the community here, this was a great hobby for me as AutoIt is what got me start with programming (even though I had tried several times to get into other languages before, those attempts were never as successful as what I have done in AutoIt).
In Linux there is no language which is similar to AutoIt unfortunately, there are a few things which come close but are not on par with AutoIt's ease of use. As some of you may know, I have recently started working on other projects using the C language, it is a great step I have taken and I am learning a lot... but it is still not easy to create quick scripts or programs in C, due to the amount of configuration and dedication it takes to make a C program, also it is not ideal for sharing as multiple source files are involved. And on top of that you still have to deal with platform-specific APIs since C is a low-level language.
(Getting back to core of this topic's subject)
To solve this issue and to sharpen my programming skills, I could start working on an alternate cross-platform implementation of the AutoIt language which should be backwards compatible with the current AutoIt v3 on C
The primary aim in the beginning is to implement all the basic functions (File, String, Numbers etc.) in AutoIt so that it is possible to make basic and fundamental scripts which would work in both Windows and Linux
The main features would be:
Cross-platform (Linux and Windows with the possibility supporting of Mac) Backward compatible with AutoIt 3 Byte-code based interpreter instead of source interpreter Easy to use (just like the current AutoIt) The advantage of having a byte-code based interpreter is that it makes the interpreter lighter and faster since it doesn't have to deal with parsing the source code, this would also open the door for some compile time optimizations... another bonus thing for those who don't like their source code present inside the compiler binaries is that it should be impossible to get hands on the original source code, this of course does not mean that decompilation can be stopped... it merely means that anyone decompiling would have to reconstruct the code from the byte-code.
We can later on implement GUI related functions and maybe even automation related functions if the project gets enough traction
I am adding a poll to keep track of people who are willing to invest in this project or would like to see it come into existence. Welcome any comments, suggestions etc.
Obviously I will have a lot to learn and my work might interfere with this at times, but with enough interest I can see myself working on this to deliver a very basic prototype which could be used with basic scripts.
I have a macro that works well on 95% of computers. However, I am running into an issue on a couple computers where the _GUICtrlTreeView_ClickItem clicks the wrong item (an item or two below the correct one). Both the ExpandItem and SelectItem command work fine, just the click item is off on these computers (and only their user names). I'm not sure if some temp file somewhere is causing an issue or what. Note, using ONLY selectitem results in inconsistent focusing (item appears focused but the next command won't always work correctly). Hence my need to use the clickitem command.
Any help would be appreciated.
_GUICtrlTreeView_Expand($hWnd, $Array2[$i]) ;Expand $model Sleep(250) _GUICtrlTreeView_SelectItem($hWnd, $Array2[$i]) ;Select $model Sleep(150) _GUICtrlTreeView_ClickItem($hWnd, $Array2[$i]) ;Click $model Sleep(150) EndIf
Only early days at this point, but I have been pondering such a program for a while.
As good as calibre is (thank you Kovid Goyal), which is a great and wonderful ebook suite of tools and a fair database, it does have its limitations. One of which, is how it deals with multiple libraries, another is the views you get. CalibBrowser will seek to address those.
What CalibBrowser is not going to be, is an editor for existing calibre libraries. That will be left up to calibre, which is very much needed still, and covers many aspects I will never look at. Unlike calibre, which is quite a complex program, CalibBrowser also seeks to be simple. It is mainly a viewer, at this point, but will later be able to create its own libraries. However, it does not and will not export them to calibre, especially as calibre employs a far different method and structure to what CalibBrowser will employ.
When CalibBrowser starts, it looks for calibre executables and the main Calibre Library. Whatever isn't found, you get prompted for with a browse option.
A calibre library, is a set of ebook folders (Author\Ebooks) and a database file, always named metadata.db, and which causes an issue when it comes to multiple libraries, but makes life a bit easier when reconstructing any corrupted libraries. However, there are better ways to deal with that, as my program will show.
The metadata.db file is an SQL database, so I am having a learning curve right now, as I have only ever dealt with an SQL database previously, codewise, when I created my INItoSQL program some time last year, as an exercise to prove a point.
At the moment, things are pretty basic, and not everything works 100%. Here is a screenshot, to give an idea of it, but keep in mind, I intend to expand the current GUI for other stuff I will be adding.
Gawd, I just noticed the '3|7' in the Book Input field (original screenshot). I was using that during troubleshooting for the multiple images scrolling and forgot to disable it ... not that it impacts anything. When it comes to maths, I struggle a bit, especially when tired. Right scrolling was easy, with a continuous loop, was easy to implement. Left scrolling was significantly harder for my poor brain ... until I realized I needed to see them as Min and Max.
As you can see the program is usable, and all the buttons, aside from the Program Information one, work. You can even load different calibre libraries, and even reload after making changes to one with calibre. The calibre program does not need to be running, even to view an ebook in the Calibre Reader. The combo selector for a library and the ADD button are only temporarily placed where they are, until I expand the GUI.
My intention at this point, is to add another five thumbnail images, directly below existing. Currently they aren't clickable, but I may add that.
Here is another screenshot, of what you see when you click the larger Cover image.
If you want to have a play with the program as is, then you will need to also get the 'sqlite3.dll' file from some online source. When CalibBrowser starts successfully with the selected calibre library, it copies its metadata.db file to a sub-folder of the program called 'Backups'. It also creates a sub-folder in that, based on the library name, to house it. That copied file, is the one the program uses, though it does not even edit that, and file modification is checked every time the program starts with a particular library, or when you Reload or select a library. If the original source file has been modified, then the program copy is overwritten. The Reload Database button does nothing, if there is no change detected, and reports such.
Place the required 'sqlite3.dll' file in the CalibBrowser root folder. Download includes source files (sqlite3.dll excepted).
Also required of course, is an install of calibre, plus some ebooks in a created library - Calibre Library is the default when you first add ebooks to calibre. The Mobile Read Forums, is a great source for all things ebook, and calibre can be found there in the E-Book Software section.
CalibBrowser.zip - Upload 4 (previous downloads: 1 + 12 + 5)
My apologies for the program being created in AutoIt v22.214.171.124. It is the first one I have done in a while, with an older AutoIt version. Basically my Win 7 Netbook, which has a current version of AutoIt, was busy and is always busy doing something, and not suitable for doing big projects for several reasons. My older but more powerful Win XP Laptop, has a better programming environment, better computer chair (most important for my knees etc), better external monitor (wider and newish), full size external keyboard & mouse, and a great suite of setup tools to assist me. I run several older versions of AutoIt already on my Laptop, but haven't yet determined what I need to adjust to add a current version of AutoIt to the mix. This also applies to my hugely beneficial Toolbar For Any program (one of those tools), which I constantly use with SciTE. At some point, when finished, I may update the program to the current AutoIt version ... especially as I believe I am now proficient enough to do so, having become quite familiar with it in the last year or so, making many programs with it.