Blogs
Our community blogs
-
- 17
entries - 4
comments - 2617
views
Recent Entries
Latest Entry
#17: Be more flexible on dates! (Part 2 - Lua)
Lua → VBScript
Some time ago I wrote about checking for being in (or out) of a time period more flexible. To recap, the GSE Time block only offers to enter hard coded dates and times, but it doesn't offer the usage of variables.
In that previous article I showed how easy it VBScripts makes to take the date/time calculation in the own hands by using CDate() to convert a string into a date and afterwards use DateDiff() for the calculation.
The beauty of the CDate() function is, that it handles all the different date formats like dd.mm.yyyy, mm/dd/yyyy, dd/mm/yyyy, a.s.o. for us. You just pass a written date like "24.12.2022" into the function, which then checks the regional settings of your Windows machine to figure the correct date/time format to identifiy the day, month and year correctly.
Of course Lua also has some nice date and time functionality, but it completely leaves the format trouble on the users side. To get a date value where we can calculate with there is an os.time() function which takes the date not as string but as a table, and we have to fill this table with all values like day, month, year, a.s.o.
This might sound more complicated as it is:
local vChristmas = os.time{day=24, month=12, year=2022}
but it becomes obvious that we can't use date strings like "24.12.2022" anymore. Unless we handle the conversion from string to table (incl. taking care of the date format) ourselves:
local sChristmas = "24.12.2022" local nDay = tonumber(StringLeft(sChristmas, 2)) local nMonth = tonumber(StringMid(sChristmas, 4, 2)) local nYear = tonumber(StringRight(sChristmas, 4)) local vChristmas = os.time{day=nDay, month=nMonth, year=nYear}
That's a lot of code just to be able to use a date string like "24.12.2022" don't you agree?
In the end I want to have a call routing which will be handled exactly like the one in the orignal article, where I can set a start and end date of my vacation as a GSE rule parameter, as string. But I don't want to do all this conversion stuff by myself.
Fortunately there is a solution, and a really easy one in fact. Behind every GSE block there is some either VBScript or Lua code which handles the action or the selected condition. Behind the Within a specified time period condition of the Time block there is a function called
function WithinTheTimeOfEx(szBeginDate, szBeginTime, szEndDate, szEndTime, bIgnoreDate, bIgnoreTime)
It takes all the parameters from the time period configuation window (as string), does all needed conversion and afterwards also the needed calucation using os.datediff().
Only thing we have to be aware of when using this function is that it uses a hard coded date format "dd.mm.yyyy" and time format "HH:MM:SS". By the way, you might have noticed from the GSE build-in functions CurDate(), CurDateTime(), CurTime() and the Server Script API function PBXUser.Now() that they also use hard coded date/time formats. You now have an idea why that is.
So, coming back to the call routing:
With the rule parameters
You can download this script from here:
Enjoy!
PS: Don't miss to take a look into the ECR - Useful Link Collection
- Read more...
-
- 0 comments
- 17
-
This post sums this great article series up. Mirjam spent quite some time to identify all those tips and to publish them here on Swyx Forum.
As the article series dates some years back there had been a couple of articles I have not re-posted again, simply because they were not valid with a current SwyxWare version anymore.
But the vast majority of the tips is still valid with current SwyxWare versions and that's why I decided to re-post them to make them available again after the old Swyx Forum went offline.
Thank you very much Mirjam for all your efforts!
- Read more...
-
- 0 comments
-
- 6
entries - 42
comments - 2045
views
Recent Entries
Latest Entry
Call Parking / Open Hold
A common feature request I have had over the years is a Call Park feature, and the usual stock reply to Can Swyx Do..... is NO! but...... of course this is software and anything is possible. I have seen a number of ways of implementing a call park feature some really clever ones that use the conference bridge facility in Swyx to some not so clever ones using analog adaptors to have live logged on extensions which are used to pick up from... sudu call park.
Before I saw the conference room version written by Tom I had a go myself and came up with this solution a couple of years ago and put it online. Recently a couple of requests came in for the source code so I thought I would upload it here.
This is another illustration of how different solutions to problems can be developed with Swyx, there is no right or wrong way, they either work or don't.So next time someone asks if "Swyx can do ......... ?", reply "No it can't, but you can" 🙂
- 6
-
- 9
entries - 0
comments - 1833
views
Recent Entries
- 9