Jump to content

Is there a CreateObject function available?


Guest joemarotta
 Share

Recommended Posts

Guest joemarotta

I am trying to convert over from VB Script WSH scripts. How would I accomplish accessing an object created from CreateObject.

For example:

Function SendEmailMsg(strSubject, strBody)

' Create email object

Set oolApp = CreateObject("Outlook.Application")

Set email = oolApp.CreateItem(0)

'Create the email contents

email.To = "name@any.com"

email.Subject = strSubject

email.Body = strBody

' Send the Email

email.Send

End Function

Any help would be appreciated.

Joe

Link to comment
Share on other sites

....which goes back to the requests to have Autoit have a mechanism (since it could be done in a number of ways) to support windows scripting/visual basic script and perhaps even Visual Basic for Applications (VBA would be huge too) within a single Autoit exe. The best mechanism for windows scripting support is best left to experts, but it would seem you might be able to tell AutoIt between a "other"script_start and "other" script_end command to copy the contents of VBscript commands or Jscript commands to a temp file, rename it vbs or js (based on command options), and then have cscript execute it (for example) via a "other"script_run type of command. Something like this, looks like its being done by Macro Scheduler.

Other macro recorders like Macro Scheduler ( http://www.mjtnet.com/ ), Aldo's Macro Recorder 4.1 ( http://www.aldostools.com/macro.html ), Macro toolworks ( http://www.pitrinec.com/toolsworks.htm ), and many more have embraced windows scripting/VBscript to increase their power and functionality.

AutoIt as a "programming language" has many, many weak areas that could take months to years to address. Furthermore, in various situations there is no intent or will, whatsoever, to address certain AutoIt shortcomings. This is why it is a shame and amazing that such a powerful automation tool like AutoIt does not embrace and have this kind of added functionality, when it comes to supporting other scripting languages, which would make it even more of a incredibly powerful program.

Many users of AutoIt are not professional programmers and have limited to very limited skills in other program languages, but AutoIt's powerful macro recorder/automation features and combined with many added commands, allow such users to still perform some very advanced computer tasks. It is in light of this scenario, that arguably many/most of AutoIt's users will use AutoIt as their DEFAULT interface for solving various complex computer tasks and will use other script languages only when they have reached various AutoIt limits and barriers.

AutoIt's editor (semi-officially SciTe) & commands as "default interface", also means that the AutoItX3 DLL does NOT address this type of problem, because by default it requires that you have a decent to high skill level in A or MULTIPLE scripting/programming languages other than AutoIt. That is because the DLL means the OTHER script or program language becomes the DEFAULT interface. A highly skilled programmer at Visual Basic or even C++, will of course, love the DLL and use it to maximum effect, but that will NOT be the case for newbie, part timers, and arguably MANY of AutoIt's users.

How many AutoIt users are expert programmers or have a significantly high level of programming knowledge??? Which is AutoIt more likely to be used for, the common guy trying to accomplish complex computer tasks as easily and simply as possible with a powerful automation/macro recorder with added functionality or as an automation tool "helper" for a highly skilled programmer??? The thing is too.... both can be satisfied by AutoIt, if the will was there.

If AutoIt had built in support for windows scripting than users could "borrow code" from another script language or even MANY script languages (via Internet or help of friends) at once to resolve a problem. It would allow many AutoIt users to just "dabble", play, or use SMALL bits of the other scripting language only when necessary and by using an Autoit EXE. AutoIt's embrace of other scripting languages would also helps its expansion of its own commands to be more focused. This ability, to handle other scripting languages, would be HUGE and is something other commercial macro recorder/automations tools have picked up on already.

Edited by autoitNOW
An ADVOCATE for AutoIT
Link to comment
Share on other sites

I've always seen AutoIt the other way around; as a lightweight language that other languages can use to integrate the features of AutoIt to accomplish tasks that could be more complex in that particular language. One of the main goals of AutoIt was to keep the binary executable under or around 100 KB in size, and as you turn a language into a host language for other languages, you must also add in size. AutoItX does address some of the features with COM control that allows many other language to use AutoIt code where it is appropriate to do so.

I don't know that much about Java or C++, but from what I do understand, I believe that you can use a higher level object oriented language with AutoItX if you have a need. Object oriented programming is also seen as a more complex form over function programming, and therefore would make it harder for new users to understand the language.

[font="Optima"]"Standing in the rain, twisted and insane, we are holding onto nothing.Feeling every breath, holding no regrets, we're still looking out for something."[/font]Note: my projects are off-line until I can spend more time to make them compatable with syntax changes.

Link to comment
Share on other sites

Using AutoIt as a mechanism to "call" other languages may not increase its size all that much. I'm talking more in terms of copying and then pasting another language's code to a temp file (for example) and having built in Windows tools such as cscript execute it. Therefore we could be talking about adding text in a script, adding a few new commands, or perhaps modifying filewrite (adapting it even more for multiple line use) and perhaps modifying run commands. AutoIt does not necessarily have to recognize the syntax of another language, but maybe do the opposite, ignore the syntax, and past it somewhere else. Regardless of how it would be done, what you would get BACK in return would be HUGE in proportion. AutoIt could overcome many of its present limitations by taking advantage of what other script languages have to offer and becoming an even more useful tool for the casual, common, part time programmer, netadmin, etc... types.

I also don't see the increased proposed functionality of using AutoIt to call other script languages and as a default interface for many users as something that takes away from AutoItX or the more highly skilled to even professional programmer that wants to take advantage of the AutoIt DLL. The 2 can easily complement each other, as different paths to get a problem solved. Like Yin and Yang, they would be 2 halves of a complete whole.

Edited by autoitNOW
An ADVOCATE for AutoIT
Link to comment
Share on other sites

I would have to agree with autoitNOW on this one .I would love it if I could use other code in this. I'm no programming and will never be one but I find things that he talks about that would help me a lot with autoit.

Lat night I found this link to rapidbatch and I think I will pay for it as I can learn it . not that hard to use .

http://www.rapidbatch.com/

Link to comment
Share on other sites

How many times must I say this? If you want AutoIt to have a "Start Other Language Segment" and an "End Other Language Segment", then write a freaking parser that will translate it into the proper AutoIt code (Such as FileWriteLine()'s and what-not) yourself? It's easy, it can be done in less than 50 lines of code.

AutoIt is not and likely will not be a host for another language directly. Even adding COM support is not making it like VBScript, COM is something that can be used from within several programming languages, VBScript just happens to make it central to it's functionality.

Edit: Typo's.

Edited by Valik
Link to comment
Share on other sites

I don't want to fight with anyone nor do i want to start a fight but I think anyone has a right to ask something and not be yelled at .

Just say no and be done with it you do not have to post a comment , just look it over if it is something that bugs you .

I found this in RapidBatch program .

wait '5000'
open firefox.exe

Stops the script until the specified amount of milli-seconds had passed. and then opens Mozilla Firefox and it does not need the full path .

Be nice if autoit would work like that .

Link to comment
Share on other sites

bob, the part that bugs me is that the last couple times this has been asked, I've mentioned a way to do it that can be done using AutoIt itself to add these "features" to AutoIt by creating a script which is called just before compiling/running which will look for a specific start/end segment and translate any language's code between those blocks into the appropriate FileWriteLine() calls and an appropriate call to whatever runs that other language (Yes, that was a long sentence). It's very simple to do it. It requires some basic file reading, a tiny bit of a string parsing, and one small bit of file writing and that's it and boom, you can suddenly do something like:

; AutoIt code
Local $var = 12
If $var <> 12 Then MsgBox(4096, "", "Your PC is dumb")

#VBS-START
Set myobj = CreateObject("some.object")
#VBS-END

Obviously that code would need to be passed through the parser/interpreter/nifty-run-time-code-replacement-thingy before being passed to Aut2Exe.exe or AutoIt3.exe before it would work.

I'v mentioned this multiple times and it's seemingly gone ignored. I'm dead serious when I say this can be done in less than 50 lines of code. There is no excuse to keep asking for this "feature" when it's something virtually any AutoIt scripter can write for themself if they'd actually stop insisting it be built-in and just try to write it.

Link to comment
Share on other sites

Valik, don't get me wrong, I definitely respect you, your contributions, and respect your proposed solution.

I think there are some issues with the proposed parser solution:

. Many don't have the ability to create their own parser. Why should every user wanting to add windows scripting functionality be forced to do this, when it could be done as a single project, properly, and included in AutoIt.

. The code would have to be fed to the parser and then to Autoit as oppose to being able to be executed in a single step via a single compiled autoit exe.

. It would seem that this method would mean that you would have to create multiple parsers for each language.

. If it is so simple than why not include it in AutoIt.

. Other automation/macro recorders do not use the parser method, but built the functionality into their programs. Obviously, such commercial companies have also given this issue some thought. I think these companies built it in, because of the huge return they get back with the added functionality.

. AutoIt's integrated windows scripting functionality or increased filewriting ability would mean LESS files, less effort, and more efficiency. How could you beat a single compiled exe?

The "end point" for many users is the compiled AutoIt exe from their script, so a small change in AutoIt's size (which will eventually happen anyway from some other new feature) would not be an issue.

Like Pekster mentioned, some users use AutoIt as a "helper" to a computer language they already know, which is why AutoItX dll is such a "killer app" for them. Other users are not programmers, limited knowledge part timers, newbies, etc... that will focus more on the "built in" features of AutoIt, the editors, and pre-built "helper" apps and scripts that the more highly skilled programmers contribute. Perhaps some highly skilled programmers would have disdain for "lesser" users, but if we wanted to do things the hard way than why even use AutoIt? Why not just force the mastery of C++, C, or even Assembly on all these "cheaters"?

AutoIt has the power to create a new path to achieve the kind of productivity you see in more complicated programming methods. Why not continue this trend? AutoIt's purity can be maintained in the DLL. The proposal to add a "mechanism" in AutoIt to integrate windows scripting in a single compiled exe does have many merits that make it worthwhile. I don't see this as x versus y, but x + y leading to something greater.

Edited by autoitNOW
An ADVOCATE for AutoIT
Link to comment
Share on other sites

Many don't have the ability to create their own parser. Why should every user wanting to add windows scripting functionality be forced to do this, when it could be done as a single project, properly, and included in AutoIt.

Or, better yet, someone who needs this can code it, and post it in the Scripts and Scraps forum where this kind of stuff is designed to go.

If it is so simple than why not include it in AutoIt.

Many things are simple that cannot be done with a single AutoIt call. We can't build support in for all of this because then you would need to order a CD to obtain it. The whole point of a language is to give you the tools you need to do something, not provide commands for every possable use of the language.

Other automation/macro recorders do not use the parser method, but built the functionality into their programs.  Obviously, such commercial companies have also given this issue some thought. I think these companies built it in, because of the huge return they get back with the added functionality.

And other companies are dependant on the payment of its users to keep it alive. This is an open source project, and thus we don't have to do something just because everyone else does.

How could you beat a single compiled exe?

IMO having a smaller binary executable is a huge benefit over extra features, especially when the features in question can be done with relative ease, or a different approach.

The "end point" for many users is the compiled AutoIt exe from their script, so a small change in AutoIt's size (which will eventually happen anyway from some other new feature) would not be an issue.

I disagree that the size will "eventually happen anyway." It is a main goal to keep the binary executable size as small as possable to allow more portability. Sure, we could just keep adding whatever features people wanted, but that would create a different language. That's not the goal of AutoIt.

Other users are not programmers, limited knowledge part timers, newbies, etc...  that will focus more on the "built in" features of AutoIt, the editors, and pre-built "helper" apps and scripts that the more highly skilled programmers contribute. Perhaps some highly skilled programmers would have disdain for "lesser" users, but if we wanted to do things the hard way than why even use AutoIt?  Why not just force the mastery of C++, C, or even Assembly on all these "cheaters"?

It has nothing to do with disdain. AutoIt was not designed to be a host language to other languages. If you need the power of some other language, then AutoIt probably isn't the right tool for your job. There is no one language that will beat all others because each one has jobs it is better suited for. If you need the power of VBscript, Java, or C++, then use that language.

[font="Optima"]"Standing in the rain, twisted and insane, we are holding onto nothing.Feeling every breath, holding no regrets, we're still looking out for something."[/font]Note: my projects are off-line until I can spend more time to make them compatable with syntax changes.

Link to comment
Share on other sites

Forgive my ignorance...but I'm trying to better understand the resistance to including VBscript or windows scripting functionality in a AutoIt script, having AutoIt copy it to a temp file, and then executed by cscript or wscript.

VBS_Start ("createobject.vbs/name of temp file", "temp file location", "other options")

; Perhaps this could be a modified FileWrite command or be called ExtSyntax_Start and ExtSyntax_End so that this method is used for simply copying contents from start to end to a temp file.

Function SendEmailMsg(strSubject, strBody)

' Create email object

Set oolApp = CreateObject("Outlook.Application")

Set email = oolApp.CreateItem(0)

'Create the email contents

email.To = "name@any.com"

email.Subject = strSubject

email.Body = strBody

' Send the Email

email.Send

End Funct

VBS_End

; Could be called ExtScript_End, etc... simply a place marker to tell AutoIt that it can stop ignoring the other scripts syntax and return to AutoIt's syntax.

VBS_Run ("createobject", "cscript or wscript", "other options")

; Could be modified Run command.

. Why can't the contents between VBS_Start and VBS_End be copied and sent by AutoIt to a temp file or file created by VBS_Start / FileWrite options?

. AutoIt does not have to understand the VBScript syntax in this method, but ignore it. Why would this not be possible?

. What size penalty, do you think this code would incur? I would think the size cost would be small and would be a much, much smaller project than say doing GUI.

. Cscript, wscript, etc... does all the work. VBS_Run would just be commands to run the created temp file createobject. vbs with a program external to AutoIt. What difficulty would be involved in creating a VBS_Run command or modified the present Run command a bit (thought that might not even be necessary with VBS_START and VBS_End)?

Edited by autoitNOW
An ADVOCATE for AutoIT
Link to comment
Share on other sites

You're absolutely right in the way it should be done and how it's done. So why can't you be content that AutoIt can do that to itself without hard-coding it? I've done as much in roughly 67 lines of code (Including whitespace and a comment header). And it's language independant (Although it is very crude, it works). I'll post more once I finish it (There are a couple quirks that need fixed).

Link to comment
Share on other sites

Valik you are still a hero. I'm sure, not only me, but a signficant number of others thank you and will thank you for your efforts. I'm not usually this much of an advocate, but I just see so much potential with finding ways to integrate windows scripting.

Edited by autoitNOW
An ADVOCATE for AutoIT
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...