EControl Ltd.

[mstaszew]

Is there a way to have the following commands smUpperCaseBlock, smLowerCaseBlock, smToggleCaseBlock, smTitleCaseBlock not change the case of strings?

Thanks.

[jfudickar]

Good idea

[econtrol]

Do you want to turn them off?

It may be handled in OnExecuteCommand or by reseting keystrokes in the keymapping.

Michael.

[mstaszew]

No, I would like the case changes to apply to all non-string text.

thanks.

[econtrol]

Really I do not understand. What does it mean "non-string" text?

Michael.

[itsatomic]

Original text:

this is an example of some lowercase text, with a "string" in it.

After UppercaseBlock:

THIS IS AN EXAMPLE OF SOME LOWERCASE TEXT, WITH A "string" IN IT

Possible gotcha examples:
1. determining string delimiters
2. incomplete strings in blocks
------------------

It's an interesting idea, but this idea, along with the "assignment swap" idea (ie a := b becomes b := a) are beyond the scope of an editor control per se (just my opinion). If Michael develops the entire editor (application, not control) for us, we will quickly become redundant. I would prefer Michael's valuable time went into documentation for a cycle or two.

sincerely,
Aaron

[mstaszew]

I disagree with you Aaron given the user audience of my application. I write software for other developers. If you as a developer have come to use an upper/lower/title case routine then you can see how capitalization changes in strings can be very bad. In the case of my users, these case changes will most likely break their code since Oracle strings are case sensitive when used to query Oracle tables/views. In other cases like if I myself used such a feature in Delphi then my user messages and prompts would be out of their intended case.

>Possible gotcha examples:
>1. determining string delimiters
>2. incomplete strings in blocks

Regarding #1. This feature of course would/could be built off of the existing architecture. All of the lexers in LexLib.lxl have a string Parser rule. I think that the string parser rule would be sufficient to use for locating strings. This rule would also satisfy your second example above. If the string rule is not satisfied then the case changes apply as normal. To remove a possible third gotcha, maybe the feature could just be one additional property of the editor that accepts a string. This string would be the name of the parser rule that should be used for ignored tokens when changing the case of text. If the parser rule specified does not exist then the case changes apply to all selected text as it does now.

>but this idea, along with the "assignment swap" idea

I haven't seen the assignment swap post yet, but the two are apples and oranges. Assignment swap I can definately see as being a specific request for one of the users, but the issue about strings is in my opinion an editor feature.

Thanks.

[itsatomic]

When I was in second year at uni, we used Vi on a Unix box to write cobol assignments (*shudder*). Cobol standard is uppercase, the vi command to move 20 lines down is 20j, but uh oh, you're still in uppercase, and 20J means join the following 20 lines into one. *Headache*

So I wrote all my assignments in lower case and wrote a simple C program that parsed my assignments, uppercasing everything except comments.

You don't want comments uppercased / lowercase / title cased either do you?

I have often had code where I copy a block and want to swap assignment around, but never used a function to upper or lower case entire blocks of code before. That's why I equated the two (I've never seen an editor do either before).

My user audience is also developers. I guess my point was I would be prepared to program an "ignore strings" function into the editor as the developer of the editor application - and the assignment swapping routine also - as they are things that will differentiate my editor from others. I am not saying they should not be done.

[mstaszew]

I never use upper/lower/title case features personally. I usually code the way that I want and run a formatter like DelFor afterwards in case I missed anything. I only ask for this because our old editor component did have settings for ignoring strings and when you have a ton of users and drop something like this on them then after the ohhs and ahhs wear off the griping starts Not sure if the old editor ignored comments though. I'll look at doing it in ExecCommand manually. It didn't hurt to ask.

Thanks.