Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Code Stored in a Variable !!! 4

Status
Not open for further replies.

lovehuman

Technical User
Apr 17, 2001
30
SG
Hi,

I have a piece of code stored in a variable. The code will change according to the user input. How can I execute this code? Any ideas????
 
Save the variable to a VB script file, run it with ShellExecute and then Kill it.

Passing variables to and from the code will prove to be a bit more difficult.

Chances are that you have chosen the most awkward approach to the problem. It is best to include all required code in your main app and then execute it conditionally, based on input from the user.

VCA.gif

Alt255@Vorpalcom.Intranets.com​
 
Yes to everything that Alt255 just said! Is there a specific reason that you have code stored in variables? - Jeff Marler B-)
 
Actually I am writing a software which allows the user to add new controls to the forms and associate actions to them. The actions are pieces of VB code. But I can't find a way to execute this code, which will be written by the user. So thats why i am trying to find alternate way of doing this.

The concept of using VB Script seems good. I will give this a try....
 
Are you adding the controls to your application at run time? If so, I would recommend class wrappers around the controls to implement your actions. You could have a DLL filled with different Class Wrappers (different actions for different control) and then create the controls dynamically at run time and pass the reference to the appropriate, instantiated class wrapper. - Jeff Marler B-)
 
Thanks Jeff for the idea. But the problem here is that the controls should execute the functions and procedures written by the user, which I will be storing in the database or in the text files. How can I use that code if I use class wrappers...
 
Don't know if this will help you (haven't tried it myself), but check out faq222-429

Good Luck
-Mats Hulten

Ps: Let me know if it works... :)
 
OK, if the user is writting the software, then you will probably have to go with the script idea. Class wrappers are nice for dynamic forms stuff, but I don't think that you are going to be able to expect you user to write their own classes. - Jeff Marler B-)
 
Check out the MSSCRIPT.OCX Scripting Control.
From
Code:
On The Web
The Script control provides a simple way for your application to host a scripting environment. Supported scripting languages are VBScript, JavaScript, and any other compliant scripting language that will work with the Microsoft Internet Explorer web browser. 

You can download the script control from the following Web site: 

[URL unfurl="true"]http://www.microsoft.com/scripting/scriptcontrol/default.htm[/URL]

This page also provides a link to documentation on how to use the control. The file name you will receive is sct10en.exe. 

NOTE: Registration is required before downloading this control. 

Visual Basic 6.0
The Script control ships with Visual Basic 6.0; however, Visual Basic 6.0 setup does not install the Script Control for you. The control is located in the CD directory Common\Tools\VB\Script. To install the script control, try the following steps: 

Copy msscript.ocx to Windows\system or WinNT\system32. 


Copy msscript.hlp and msscript.cnt to Windows\help or Winnt\help 


Copy dispex.dll, jscript.dll and vbscript.dll to Windows\system or Winnt\system32. 


NOTE: If you have newer copies of these DLLs on your system, do not overwrite them. 


Register msscript.ocx using RegSvr32.exe. Example: 

Regsvr32.exe c:\windows\system\msscript.ocx
 
???????? Is this 'back to the future again' or what????

It sounds like a bad idea goen badly awry. If the 'Users' are able to write the code, they should just be given VB IDE and let loose. Otherwise, lock the door and throw away the key. Between lies only degrees of madness (in an infinite number of dimensios!).

Other than the above, Let them use Ms. Access or Excel to develop prototypes of their needs and give this material to a 'professional' to integrate into a package. Believe me the frustration level will be less than if you have to do the hand-holding.


MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over
 
1) It was a faulty idea in the beginning. 2) Users should have certain control. 3) Admin should be able to control the system.

I don't see a problem. I see a solution requiring exposure.
VCA.gif

Alt255@Vorpalcom.Intranets.com​
 
Okay let me explain you guys. The situation is something like this:

We have a highly configurable software. Which have multi-level of users. The highest level (on client side) are the local administrations who are well versed with VB. The software need to be changed from client to client. We have a generic set of properties and fields rest are all dependent on the user.

Basically, the code can be written by the implementation team or the local administrators to some extend.

I don't know if it is a good idea, but I am sure if u need such a configurable software you have to use some techniques which are not good in normal scenerios.
 
It sounds to me like you are attempting to create a framework that you can use to create other "client specific" programs. This by itself is not a bad idea . . . frameworks are wonderful things that make our jobs much easier. But you need to consider if you really want your clients to have access to the code and how often is this code going to change. Go ahead and create your framework with your "a generic set of properties and fields" . . . I think that you will find value in that. And then, if you expect to see many change in the application, then add extensibility hooks into the code, that will allow you to add/replace client specific modules in the future.
- Jeff Marler B-)
 
Okay, exposure #1: You can retain control of the systems while allowing an acceptable interface by creating a bogus OS. This is an interface that mimics the UI while blocking some of the OS features. My first experience with this ghastly type of add-on occured 10 years ago when I found that my employer allowed me to copy files but not delete them. (They called it FakeDOS but it was just "DOS" until I realized it was present and found a way around it.)

This type of environment is very easy to create with VB... but very hard to promote from the management side....

Remember this: you can control every user action in Windows (aside from a powerdown or a system reset) but you will never control the users.

Writing and executing VB scripts from your app should meet your basic requirements... but you should consider adding a few filters to prevent [tt]Kill "*.*"[/tt] (and a few others).
VCA.gif

Alt255@Vorpalcom.Intranets.com​
 
I have used the MSSCRIPT.OCX but I have not experimented with the UseSafeSubset property but here it is for what its worth.
Code:
Sets or returns a Boolean value indicating whether the host application is concerned about safety. UseSafeSubset is True if the host application cares about safety; False if it does not. Read/write.

Syntax

ScriptControl.UseSafeSubset [=value]

The UseSafeSubset property has these parts:
If value is True, access to some objects and procedures is not allowed.

Remarks

The scripting engine in use determines if, and when, the UseSafeSubset property is set. If no language is specified (
Language property), the UseSafeSubset can be set at any time.
The objects and procedures that can't be used when UseSafeSubset is True are identical to those restricted by the browser's highest security setting.
P.S. The FileSysteObject.Textstream.ReadAll method is handy for reading an entire Script Module into a string to be passed to the ADD method of the control.
 
I have to agree with Alt255 on the Filter idea . . . if your users are going to be writing their own scripts, then this will be very important (considering the fact that most viruses these days are simply some form of script). - Jeff Marler B-)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top