Simulating Debug.Print on a Form

[Trexx]

Hello everyone,

I have a form on which I've placed a textbox. The object of the textbox is
for the user to enter command-line math and have access to all the built-in
Access functions (math, text, date, custom-built) without complicated or
cumbersome interfaces. For example, the user could type:

23 / 15 =
int(rnd() * 100) + 1 =
DayOfWeek(now()) =
....etc.

So the user would type whatever he wanted to know just as if he were using
the debug.print on the immediate window, click on a button, and Access would
return the answer, again, just as if the text had been typed on the
immediate window:

? 23/15 (enter)
? int(rnd() * 100) + 1 (enter)
....etc.

I trued using the docmd command but none of the arguments allows it to do
anything like it. The closest solution I could think of was to create a
bogus table and run my command-line math as an SQL statement, only to
retrieve my answer on the first (and only) record created from that query...

Frankly, that seems like the long (and cheesy) way to do something simple.
What more direct way is there to run typed commands from a form? Thanks
in advance,


Juan

 

[Allen Browne]

Try Eval()

 

[Marshall Barton]

I have a form on which I've placed a textbox. The object of the textbox is
for the user to enter command-line math and have access to all the built-in
Access functions (math, text, date, custom-built) without complicated or
cumbersome interfaces. For example, the user could type:

23 / 15 =
int(rnd() * 100) + 1 =
DayOfWeek(now()) =
...etc.

So the user would type whatever he wanted to know just as if he were using
the debug.print on the immediate window, click on a button, and Access would
return the answer

No code or even a button needed.

Use a second text box to display the result by using the
expression:
=Eval(firsttextbox)

BUT, you are leaving the door wide open for users to enter
something that could destroy your system. (e.g.
Shell("myvirus")

 

[Trexx]

Worked like a charm. Thanks!

As far as the security "hole" that I've opened with it, could I simply not
process any exressions that may contain the string "shell" or "cmd" in it?
If so, what other text should I block from executing?

Thanks again,

Juan

 

[Marshall Barton]

Worked like a charm. Thanks!

As far as the security "hole" that I've opened with it, could I simply not
process any exressions that may contain the string "shell" or "cmd" in it?
If so, what other text should I block from executing?

I don't have a list on the top of my head, but you could try
searching the KB for Sandbox Mode to see what MS thinks are
"dangerous" functions.
--
Marsh
MVP [MS Access]