Passing Intrinsic Constants as string names

Topic

New Reply

I want to execute runcommand with a parameter, something like:
RunCommand myParameter

The problem is that I want to store the values to myParameter as strings; that is, I want to store the string “acCmdZoom100” and not its numeric equivalent. Then I want to somehow be able to convert the string to its numeric equivalent so it can be properly processed. So I need a function to do this conversion, so I can use:
RunCommand myFunction( myParameter )

I thought this could be done with Eval, but I can’t get it to work. Any ideas?

Reply | Quote

Replies

I can’t visualize what you’re trying to accomplish. Why are you trying to store the constant name and use that instead of just passing the constant? If you’re trying to build a routine to call the RunCommand method, you’d be better off setting it accept a variable declared as an acCommand enum and passing the actual constant into the myCmd argument something like this:

Public Function TestRunCommand(myCmd As AcCommand)
  RunCommand myCmd
End Function

Reply | Quote

In this situation, I want to store a user option for a Zoom setting for previewing reports. In the option selection form, there would be a combo box, which would contain the string names of the runcommand zoom constants, that is: “acCmdFitToWindow”, “acCmdZoom75”, “acCmdZoom100”, etc. So, I would store the string name (not the numeric equivalent). Then when it comes time to run the report, I want to convert the string name to the numeric equivalent so I can use it with RunCommand.

Yes, I know I can store the numeric value, but then I’d have to dig-out the values (ex., acCmdZoom75=241), and I wanted a method in which I didn’t have to do that. After all, isn’t that one of the benefits of intrinsic constants?

Reply | Quote

This may be Mr. Obvious coming out here, but couldn’t you just have a hidden column in your combo box with the numeric values stored – and only show the text column to your users???

Reply | Quote

Yes I could do that, but that’s what I wanted to avoid, having to determine what the codes are. I can envision other scenarios, and it would be nice to be able to specify a string containing a constant name which could be evaluated into the property value. For example, if you use the StrConv function in an SQL statement, you can’t use the intrinsic contstants such as vbProperCase. You have to remember what the code is. It would be nice to be able to get it using a function, something like:
getConstant(“vbProperCase”)

Reply | Quote

Mark,

you can find the values for those constants easily in the Access object catalogue under Constants. Just click each constant you want and you’ll see the value in the definition below. Then you can set up a table which you can keep for further use too.

I did something like that for OpenForm command in the switchboard. I put supplemental columns with DataMode and WindowMode in SwitchboardItems.

As for the benefit of intrinsic constants, IMHO it is mainly the more easy writing and reading of the code. One remembers acDataErrContinue and what it’s for, but not the value of it – remember WordBasic in OLE automation with those awful number worms?

Reply | Quote

I know where to find the values, I was just looking for a way to do this so I didn’t have to find the values! It looks like I may have to create a constant/value table.

Reply | Quote

Sorry about that Mark. However, is that really so much different from storing the strings the way you originally planned? You’re just storing an additional value, after all.

Reply | Quote

It really wasn’t about having to store the value, it was more about having to know the value at all! Also, I thought that would make it easier to use. For example, take this bit of code:
RunCommand getValue(“acCmdZoom75”)

I can put a DLookup in the getValue function to retrieve the actual numeric value. But if there was a way to convert the string directly to the intrinsic constant, it would be faster and cleaner.

Oh well, it was thought.

Reply | Quote