Converter Options

[StanHelton]

A TYPE to control user options. Please add anything you think should be there or that I've left out (dendrons, you know) So far they're T/F or 0/1 members, most drawn from the VB code. the LineByLine members are user-selected.

TYPE ConverterOptionsType
    DefaultArrayBase AS LONG            '0 or 1
    CaseInsensitiveCompare AS LONG      '%False = Normal PBWin compare, %True = case insensitive compare (UCASE$ required)
    DimAll AS LONG                      '%False = OPTION EXPLICIT not present in VB code, %True = present
    PrivateModule AS LONG               '%False = OPTION PRIVATE MODULE not present in VB coe, %True = present
    LineByLineProgress AS LONG          '%True = user selected, %False = very fast, if any updates
    LineByLineEdit AS LONG                '%True = user selected 1 at a time

END TYPE

The PrivateModule is an advanced option used only in multi host/server environments, but since it's there we should probably deal with it. There's no equivalent in PB, it's a VS thing, I think.

Stan

[Rodney Hicks]

TYPE ConverterOptionsType
    DefaultArrayBase AS LONG            '0 or 1
    CaseInsensitiveCompare AS LONG      '%False = Normal PBWin compare, %True = case insensitive compare (UCASE$ required)
    DimAll AS LONG                      '%False = OPTION EXPLICIT not present in VB code, %True = present
    PrivateModule AS LONG               '%False = OPTION PRIVATE MODULE not present in VB coe, %True = present
    LineByLineProgress AS LONG          '%True = user selected, %False = very fast, if any updates
    LineByLineEdit AS LONG                '%True = user selected 1 at a time
    PBversion AS LONG                      '0 for PB 8 or 1 for PB 9?
END TYPE

I am curious.
Isn't setting this up as a type instead of just EQUATEs going to mean extra programming overhead, or is it just the same thing only different?
I believe in PB 9 the value of an EQUATE can be reset if it has not been used.

[StanHelton]

You might be thinking of the %DEF operator which allows checking whether the equate has been defined. The value of PB equates is determined at compile time and a second definition gives a DUPLICATE EQUATE error if the two definitions don't match.

Why a type instead of equates? Personal preference actually. My reasoning is that a TYPE lends itself more to self-documenting code. Here's the list of equates and types I'm working with right now. Some of these are already redundant, others will likely get modified greatly before we're ready to release vb2pb.

[Rodney Hicks]

Under ADDITIONAL CHANGES in the online manual(PB 9):

Any numeric equate or string equate which is pre-defined in the compiler may be assigned a revised value if the new assignment is performed before the equate is referenced in the program.

[John R. Heathcote]

Stan,

Although either a UDT or equates would work in this case, I tend to like TYPEs for grouping like functionality together as equates can (and usually do) end up being scattered throughout your source code. The more equates you have the worse this problem evolves over time. Forgetting to reorganize your equates to group like functionality together is similar to forgetting to remove unused variables in your procedures, it's not intended, but it happens over time.

I guess I'm overly dense today, but what is the point of your "options", to control conversion by the user, or to find out what is in the VB source code?

I need clarification here, and maybe some drugs to control my allergies which have flared up today.

[StanHelton]

Under ADDITIONAL CHANGES in the online manual(PB 9):

Okay. I missed that one. Building vb2pb to take advantage of this feature requires some way to track whether it's been used, I assume. Is that your understanding?

It's a different concept. I'll have to let it stew in my brain for awhile before I can integrate this.

[StanHelton]

Stan,

Although either a UDT or equates would work in this case, I tend to like TYPEs for grouping like functionality together as equates can (and usually do) end up being scattered throughout your source code. The more equates you have the worse this problem evolves over time. Forgetting to reorganize your equates to group like functionality together is similar to forgetting to remove unused variables in your procedures, it's not intended, but it happens over time.

I guess I'm overly dense today, but what is the point of your "options", to control conversion by the user, or to find out what is in the VB source code?

I need clarification here, and maybe some drugs to control my allergies which have flared up today.

It started out as a way to track the options in the code, but thinking about our recent discussion on user-options and CCL I thought we might use the same structure to track both. May have to separate them out for later versions, but for v1 I think keeping everything in one place makes sense.

I'm a little scatter-brained lately myself, so if I'm not making sense, somebody please tell me.

[Rodney Hicks]

Stan, John,
Both of you are more familiar with VB than I and have a better idea of how to handle some of the issues that we'll be facing because of that and I was just wondering, not stating a preference.
It does seem..well, unusually prescient, even of PB, to come out with an EQUATE that can be changed just when something like that would be handy.

[John R. Heathcote]

Stan,

It started out as a way to track the options in the code, but thinking about our recent discussion on user-options and CCL I thought we might use the same structure to track both.

See my latest post in "Dictionary" topic for my detailed answer to your query. Personally, I don't think it is necessary to keep track of CCL commands this way as I feel this is more of an editor issue than conversion issue. Although conversions can be performed (some simple level 1 replacements for example), I think CCL will be more effective as a tool to perform various source code utility and cleanup functions that need to be repeated before and after conversion.

[John R. Heathcote]

Rod,

Both of you are more familiar with VB than I and have a better idea of how to handle some of the issues that we'll be facing because of that and I was just wondering, not stating a preference.

I have to defer to Stan on this one. My projects were put together just to make a concept work and I really didn't delve too deeply into VB's inner workings, or take advantage of its capabilities, such as they are.

It does seem..well, unusually prescient, even of PB, to come out with an EQUATE that can be changed just when something like that would be handy.

I've always wondered about Mr. Zale's uncanny ability to read our collective minds and give the users what we want and need, although we don't know it at the time. Sounds like a real conspiracy theory is developing here.

[Rodney Hicks]

Sounds like a real conspiracy theory is developing here.

One I can live with.

A year or so ago there were a couple of posts somewhere in the fora regarding this, where the individuals wanted EQUATEs they could assign new values to. I had thought, maybe even suggested that they just use GLOBAL variables. This converter being the first instance of actually seeing a good use for the added feature.