Problem with Formula Property Definition

[mflure.80520]

Greetings all..

I'm about ready to pull my hair out on this one.. And its probably a simple solution.. This is my code as follows so far:

DrStyl = CStr([DoorObjects:Style])
Select Case DrStyl
Case Bipass
DrStyl= "BIPASS"
Case Else
DrStyl = ""
End Select
RESULT = DrStyl

I'm trying to get this formula to assign door type so I can use my door tag notation to say BIPASS & BIFOLD based on my style names. everything else will be blank (Ie.. Single swing door would be shown as 2468 but a Bipass door would be shown as 5068 BIPASS). So far everything either sets itself to BIPASS or Blank.. and It's not working.. can anyone tell me where I'm going wrong..

Thanks,

Mike

[dkoch]

I assume you are going to take the results of this property and concatenate it with the size elsewhere. I assume that you have Door Styles named "Bipass" and "Bifold" [???] and that all others should return an empty string.

First observation: Shouldn't the
Case Bipass
line really be written
Case "Bipass"
since you are assigning a string value to the DrStyl variable in the first statement. I am surprised that with out the quotation marks you are getting any matches for this case.

Second observation: If you expect this property to return "BIFOLD", then you need to add a case that will do so. But perhaps this is your first draft and you wanted to get "BIPASS" working before adding "BIFOLD". If the above change makes "BIPASS" work, then add
Case "Bifold"
DrStyl = "BIFOLD"
before your Case Else line.

Third Observation: I find using the DrStyl variable twice - initially to hold the style name and then to hold the desired output name potentially confusing. It may work, but if you are concerned about wasting resources, why not simply set the desired value to RESULT? [Using a variable would make sense if you intend to tack on the concatenation of the opening string in this property, as well, once you get the Select Case part working - if so, I would probably use a different variable name.]

[mflure.80520]

David,

I agree with you on most of your points. But the problem still exists..

In the code above.. I actually had a Case Else statement for test purposes set to "JUNK" when if the Door was not a bipass. Ive tried both "Bipass" and Bipass in the case statement. When I use the "Bipass" everything in the schedule is set to junk. if I set it the Bipass then everything is Bipass. Ive checked all of the Upper and Lowercase items in the style name, but still no idea on what the actual problem is. I was going to write the code as follows:

Select Case [DoorObjects:Style]
Case "Bipass"
RESULT = "BYPASS"
Case "Bifold"
RESULT = "BIFOLD"
Case Else
RESULT = ""
End Select

I'm thinking this should work so I can use the results in my DoorTag.. But This doesn't seem to work at all. since everything is then set to BIPASS, and if I take the "" out then everything is nothing. even though I have this attached to multiple style doors. Any Ideas??

Michael

[dkoch]

Can you post a zip file containing a drawing file that has a representative sample of the various styles of doors you are trying to tag and your Property Set Definition, including your current formula property? It is hard to diagnose what might be wrong just on written descriptions of a file.

[mflure.80520]

Ok..

Sorry that was a no brainer wasn't it... here is the file..

I even attached a schedule.. For a check..

Thanks in advance..

Mike

[mflure.80520]

Update...

I found one of my problems last night. I had spaces in my style names which was causing problems for me. Now after renaming the style names to a one word style names, Its either making everything the first case option or the Case Else. So I'm way out of my legue now. I bought a VBScript book to see if it was typed in wrong, which it isnt since its exactly to what the book mentions.. Does anyone know what's missing?? Help!!!

Mike

[richard.binning]

I'm not sure what the default compare option is set to (David do you know?), but you might try forcing uppercase on your choices to eliminate the problems associated with case sensitivity.


Select Case UCase([DoorObjects:Style])
Case "BIPASS"
RESULT = "BYPASS"
Case "BIFOLD"
RESULT = "BIFOLD"
Case Else
RESULT = ""
End Select

[dkoch]

The attached file may be doing what you want it to do, take a look and let me know. Richard's suggestion to force strings to upper case was a good one. In my example, I did that, and also forced the style property being read in to be a string by enclosing the property reference with double quotes.

Having spaces in your style names should not be a problem, provided you enclose the comparison string in double quotes [as Richard showed in his example]. Also note that your sample file had two styles with "Bifold" in the name but none named "BIFOLD", so none of the styles in your drawing would match "BIFOLD" [even after forcing to all caps].

I chose to add additional cases to match each style in your drawing. You may not find this to be acceptable, as you could have many more styles. I can think of two options to avoid this: set up a style-based property set definition and add a manual property in which you classify the door type, using "BIFOLD" for all bifold door types, regardless of style. This requires a little extra effort when creating a new style, but makes the comparison process easier. The other option would be to always start the name of your style with the desired keyword ["Bifold", "Sliding", etc.] followed by a specific character, such as a space, that would not be used in the keyword. You could then take the style name, find the position of the specific character using the InStr function, then use the Mid function to trim off the balance of the string, leaving only the keyword. Either way will require that styles or the value entered into the "style type" property be carefully done.

[mflure.80520]

ABSOLUTELY AMAZING!!!!...

Thanks Richard & David.... I really appreciate it!!!!!

Its just amazing how one function can actually change the results. That worked perfectly. I'm off and running thank you very much.. If I may ask, what is a good resource book/web site that I may read on to improve my VB Scripting abilities, It never seems to amaze me that there are several ways to write code but really only one correct way that it will work... <GRIN>...

Thanks again..

Mike

[richard.binning]

Here is a blog (http://www.integr-8.com/besidethecursor/2005/08/adt-vbscripting-resources-list.html)I just posted with some links to help you along your journey.

RLB

[dkoch]

Of the two reference books I have, VBScript In A Nutshell (http://www.amazon.com/exec/obidos/tg/detail/-/0596004885/qid=1124404138/sr=8-1/ref=pd_bbs_1/104-4399489-5626324?v=glance&s=books&n=507846) is my preferred source, mostly because the way it is organized seems to work best when I am trying to find a function for a formula. I also have the first edition [Copyright 2003] of VBScript Programmer's Reference, which now appears to have a second edition (http://www.amazon.com/exec/obidos/tg/detail/-/0764559931/qid=1124404138/sr=8-3/ref=pd_bbs_3/104-4399489-5626324?v=glance&s=books&n=507846) out. Both books have a section listing functions; I happen to prefer the Nutshell version myself, but either can be used. Keep in mind that I only use VBScript for ADT formulas, so this is all from that perspective. I can not say which book might be better for other uses of VBScript.