Leaderboard

@Exit I suppose you can make an april fool joke at any day in april if you are brave enough

It's 4 days too late for an april joke.

Based on the Outlook UDF written by wooltown, we (wooltown and I) decided to extend the functionality of the Outlook UDF. As the OutlookEX UDF ("EX" like "extended") has a completely different approach compared to the Outlook UDF it's a complete rewrite. We would like to discuss the design of the UDF with the community. Every feedback, function request etc. is highly welcome. As soon as the discussion shows that we are on the right track we would like to release an alpha version for everyone to test. So please don't be shy and post what you think of this UDF or what functions you need! Every item in Outlook is uniquely identified by EntryID and StoreID. The default StoreID is your inbox Every item has properties to describe the item (subject, startdate ..) and methods to act upon the item (move, delete …) The search and action functions are now separated. As an example the user first searches for the items to be deleted and then calls the delete function If a method can be used for more than one item type (e.g. mail, calendar and notes) the function is called _OL_ItemXXX else the function is called _OL_CalendarXXX The number of properties you can get or pass to most functions is not limited by the number of parameters defined for the function. Properties can be passed as parameters (up to 10) or in an unlimited array as parameter 1 The UDF allows to access all kind of folders (see the following listing). Folders can be passed by name or as an object to a function A lot of testing is still needed as we have written and tested the functions using Outlook 2002 SP3 and Outlook 2010 "wrapper" or "shortcut" functions will be available to let you do all tasks in one go e.g. _OL_Wrapper_SendMail for all functions above. Documentation: The documentation for this UDF (aside from the docu in the UDF itself) will be placed in the AutoIt Wiki. So we can easily modify the docu without releasing a new version each time. There will be pages describing the UDF in general and pages for individual item types (like mail) with detailed information and a lot of tips & tricks. Tested with Outlook 2003 and 2010. Some users reported that it works with Outlook 2013 as well. Starting point: http://www.autoitscript.com/wiki/OutlookEX_UDF_-_General Download

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 just noticed that Outlook does not allow to import iCal events programmatically. I might implement some of the iCalendar data format (RFC 5545) if someone is interested Please post here or click the "Like" button if you think this is a good idea Edit: For download please see my signature

@Xandy You might be talking about the bash scripting language, it is indeed a programming language which works with the popular bash shell. It is not really as graceful as AutoIt though...

Same here. I only go back to the automation part when I need a quick way to do something I'm too lazy to do for myself.

I thought Unix had a shell scripting language. I used in Tech school about 20 years ago. That seemed like AutoIt for Unix. Edit: I almost completely forget the name of what I am talking about.

AutoIt is closed source and Jos is part of the AutoIt Team, I doubt Jon would give me access to the code to port it... and I imagine it would be very hard to port the existing codebase. What I want to do is port the bare minium first as I have mentioned, we can take things from there.

An easier way would be to comment out all the lines that you declared the variables in, and see where the errors are. You did declare all your globals at the start of the script right? 😉

@caramen Yes, you are over complicating things. Just call _WD_WaitElement in a similar fashion as _WD_FindElement. If you examine the underlying code, you'll see that it just calls _WD_FindElement in a loop. FYI, I believe there are some examples of using this function in this thread or the related one.

got it a bit updated. code and compiled executable in this SourceForge project. i'm planning to integrate it into this:

Hi, Found the problem - _ArrayAdd splits the input on the "|" as it thinks it is a delimiter. An easy fix - just change line #552 in your "AutoIt3 Folder\SciTE\SciTEConfig\AbbrevMan.au3"to read: _ArrayAdd($aUser_Abbrev, $sAbbrev_Name & "=" & $sAbbr, Default, Default, Default, $ARRAYFILL_FORCE_SINGLEITEM) That bug has been sitting there waiting to happen for a long time (I since I rewrote the Array library in 2014, you can read all about it in this thread) - obviously very few people ever use the Abbreviation Manager to add abbreviations with the cursor set character! M23

maniootek, An amended UDF with a quick sanity check of the columns to be sorted: Please let me know what you think. M23

@scotspgc If the line in the MsgBox became too long, then a new line character is added automatically. If you want to use a MsgBox style form, then you need to create your own; otherwise, if you are just debugging, you could use ConsoleWrite()

If you have the full Scite4AutoIt3 installed on your version of SciTe, then you can add this directive to your script. #Au3Stripper_Parameters= /MO This will output an .au3 file with all of the used includes, and all of your script into one file.

maniootek, No - neither do I check if the user brushed their teeth last night or is wearing clean(ish) underwear. There is a fine line between making UDFs idiot-proof (which is evidently impossible) by adding significant error-checking code, which both inflates and complicates the UDF, and leaving some things to the intelligence of the user. In this case I felt that as the user required specific columns to be sorted it was likely that they would correctly enter the column numbers in the array - which I take it you did not and so got an error. I will take a look and see how difficult it would be to check the indices in $aSortData - but do not hold your breath. M23

whoa, that's still a bit over my head (again...) - but i might revisit that if and when i get to something that needs decent logging... meanwhile, what i did for this project is a tad bit more simple. it accepts two files as parameters, passes them to the diff-match-patch library, and reformats the output: ''' arguments: if <2 or >3 : show general help & exit 9 if error reading #1,#2 : show specific cause & exit 8,7 if #3 not specified : output to stdout if #3 specified but error opening it for writing: show specific cause & exit 6 ''' msg_help="" msg_help+="\n" msg_help+="program: diffdmp.exe\n" msg_help+="type: Win32 console application\n" msg_help+="version: 1.0\n" msg_help+="\n" msg_help+="purpose: compare two text files (typically two versions of a text) using\n" msg_help+=" the diff-match-patch library, with semantic cleanup. produce an\n" msg_help+=" ordered list of additions, removals and identical text sections\n" msg_help+=" which allows for clear presentation of the differences, as well\n" msg_help+=" as recreating each of the texts.\n" msg_help+="\n" msg_help+="reference: https://github.com/google/diff-match-patch\n" msg_help+="\n" msg_help+="usage: diffdmp.exe older_file newer_file [diffs_file]\n" msg_help+="\n" msg_help+="arguments: older_file : the first file to diff (typically the older version).\n" msg_help+=" newer_file : the other file to diff (typically the newer version).\n" msg_help+=" diffs_file : [optional] where to output the result. default=stdout" import sys if len(sys.argv)<3 or len(sys.argv)>4: print(msg_help) sys.exit(9) try: text1 = open(sys.argv[1]).read() except IOError: print("Error reading the older file:",sys.argv[1]) sys.exit(8) try: text2 = open(sys.argv[2]).read() except IOError: print("Error reading the newer file:",sys.argv[2]) sys.exit(7) if len(sys.argv)==4: try: diffs_file=open(sys.argv[3],"w") except IOError: print("Error writing to diffs file:",sys.argv[3]) sys.exit(6) else: diffs_file=sys.stdout ''' main function ''' import diff_match_patch as dmp_module dmp = dmp_module.diff_match_patch() dmp.Diff_Timeout = 0.0 diffs = dmp.diff_main(text1, text2, False) dmp.diff_cleanupSemantic(diffs) ''' output ''' diffchar=["-","=","+"] for diff in diffs: print(diffchar[diff[0]+1]+str(len(diff[1]))+":"+diff[1], end='', file=diffs_file) i wrote this with python 3.4 on Windows XP (clean installation with SP2), then compiled it with PyInstaller (made a resource file with version details in it and stuff, added a simple cmd icon) - and it works! and no messing about with compatibility of dependencies! even with a rather old msvcr*.dll it works out of the box! me be happy. P.S. will test further to see if adjustment of parameters is needed, if so i can easily add them to the arguments parsing routine. P.S.2 if you see anything extremely dumb in my code above, do feel free to point it out. my first python script and all...

Thank you for sharing this useful script. As my previous speaker will save a lot of time and work. Regards mlipok

Thank very much Wayfarer, it save me a lot of time.