"With / End With" construct missing from PB?

[WesWesthaver]

I have been reading the on-line documentation for the new PB and it appears that the "With / End With" construct found in VB and VBScript is missing in PB.

I always found the "With" statement to be a really nice way to tickle multiple properties and methods of an object without having to reference the object over and over again. I also feel that it makes your code cleaner and easier to read:

With MyObject

.PropertyA = this
.PropertyB = that
.PropertyC = theotherthing
.DoMethod

End With

Does anyone know why this construct is missing? Will the "With / End With" construct be added to PB?

[Rodney Hicks]

Guys,
PowerBASIC is not VB.
Something that is not in PB that never was in PB is not really missing.
Programming in PowerBASIC is not programming in VB.
Programming in PowerBASIC may require different thought processes than those acquired by users of VB or any other language.
Change, while at times bewildering, can be good for you.

[Ian Webling]

Rodney,

What Wes and, to a lesser extent, Vladimir are asking is not for PB to become VB (only two and a bit of Vladimir's requests are actually found in VB) but, with the WITH/END WITH statements, to become a little more user-friendly. For example, once using COM to access MS Word it could not be considered unusual to have lines such as:

Word.Documents.Add.Headers(%wdHeaderFooterPrimary).Range.Font.Name = sFontName
Word.Documents.Add.Headers(%wdHeaderFooterPrimary).Range.Font.Size = rFontSize
Word.Documents.Add.Headers(%wdHeaderFooterPrimary).Range.Paragraphs.Alignment = %wdAlignParagraphCenter
Word.Documents.Add.Headers(%wdHeaderFooterPrimary).Range.Text = uDay.Name

Now, while there are workarounds to code such as this, they involve creating temporary variables. In VB one could write:

WITH Word.Documents.Add.Headers(%wdHeaderFooterPrimary).Range

.Font.Name = sFontName
.Font.Size = rFontSize
.Paragraphs.Alignment = %wdAlignParagraphCenter
.Text = uDay.Name

END WITH

[jcfuller]

How about a macro?
MACRO wdah=Word.Documents.Add.Headers(%wdHeaderFooterPrimary).Range
wdah.Font.Name = sFontName
wdah.Font.Size
wdah.Paragraphs.Alignment = %wdAlignParagraphCenter
wdah.Text = uDay.Name

Not tried.

James

[Rodney Hicks]

It seems a little unjust to me to be complaining about what isn't in PB 9 less than a month after PB released a new version just because it might have been in some other language.

Had they sent in NFSs requesting those features?
Not that that means if they had the feature should appear.

It seems to me that PB gave us plenty of tools for us to get our heads around, needful tools. The luxurious tools can come later, if at all.

By focusing on what PB has, you'll find a way to get your job done.
By focusing on what PB hasn't, you won't get very far.

[Paul Squires]

Email your suggestion directly to PowerBASIC. I emailed my wish for With/End With a year to two ago. I always found that With/End With made the code much more readable especially in situations like Ian descibed with multiple "." levels.

The more people who request it, the better the chance that it will be implemented.

[Michael Mattias]

Now let's see the list of what's missing in VB.

[José Roca]

Now let's see the list of what's missing in VB.

In the first place, it can't use low-level COM servers. For example, to use DirectX, M$ had to develop ActiveX wrappers, as they did with DirectX 7 and 8. They not longer do it, so VBers can't use DirectX 9 and 10.

[José Roca]

Oh, and what about multithreading...

[Michael Mattias]

I haven't worked with VB since VB3, but I will posit that at one 'reply' per 'missing VB feature relative to PB' this thread would be a serious contender for longest ever.

[Roberto Valois]

...one 'reply' per 'missing VB feature relative to PB'...

ASM.

[Kev Peel]

Here are 10 simply Great things missing from PB that VB has:

• No fat, bloated runtime files and compatibility issues with said files
• Ability to NOT create standard Win32 DLLs
• Random crashes in the IDE and programs
• Quad variables NOT supported
• No enforced UNICODE strings
• No buggy printer object
• PB has thread support, this is BAD
• No enforced code formatting (our way, or the highway )
• Full support for the Windows API disabled
• PB is supported and actively developed, also a BAD thing

[Ian Webling]

I will posit that at one 'reply' per 'missing VB feature relative to PB' this thread would be a serious contender for longest ever.

Amen, or as they say in VB: END.

[Theo Gottwald]

Not to forget, one of the biggest strenghts in PC History was always backwards compatibility.

That was true for windows for long years, too.

We remember that Intel had to dig the ITANIUM, because AMD had 64 bits and was compatible.

PB is still compatible, this means we can re use our code!

Those using VB and now re-compiling with DOTNET will often see small wonders happen. Where I am actually on project, some programms got buggy and bloated after the conversion.

In PB you can just re-compile it, and under good circumstances the result becomes even faster (see #OPTIMIZE ...).

Besides that, there are always open wishes for a new PB release. No chance for Bob to think of getting penssioned.

I have already mailed some wish in, and I'd also support those I have read her.

The good news is, when they may be fullfilled with PB 10, we can still use most or all of our old code!

[Richard Angell]

Most, if not all, items mentioned in the first 2 posts were and still are on the wish list. The same rationales have been advanced to support them too. However many of these requests also have means to accomplish the tasks now as well, albeit not as automatically or succinctly.

Consider EXTRACT$ (et al mentioned) in reverse and take a look at using STRREVERSE$ then EXTRACT$ and STRREVERSE$ that result. This has been demonstrated here in the forums and I have used the technique for some programs where such use helped tame some strange strings. It can work with the other reverses as well, albeit this is not the automated, rocking chair way some would like it.

[Rodney Hicks]

Thanks Rick, for that info.
It supports my earlier post:

By focusing on what PB has, you'll find a way to get your job done.
By focusing on what PB hasn't, you won't get very far.

[Edwin Knoppert]

>No fat, bloated runtime files and compatibility issues with said files
This is soo yawwnn, the never ending runtime issue.
Even nowadays where the runtime is present on any supported os.
You can create incredible light-weight apps with VB6 nowadays.

>Random crashes in the IDE and programs
Never seen, unless i used generic dll's and did not unload them properly.
Just keep on breaking (hitting end) your running app guys..

>Quad variables NOT supported
For a nearly 100% unicode tool it's indeed unhandy not to have quads.
The win32 env. has a few needs.

>No enforced UNICODE strings
Since Windows fully suported unicode in the os, programming languages are better of being unicode as well.
(Being compatible)

>Full support for the Windows API disabled
My main complaint about VB, no linking but copying win32 parts in to the project, that s***s 100%

>PB is supported and actively developed, also a BAD thing
Nonsense imo, nothing as good a stable but no longer supported development tool
No more changes like with VB3's VBX's and such.
"Our program can not run, there is a newer VBX installed on your computer"
I'll never encounter this issue
(Though, we have abandoned VB3 since this year completely, the app was finally renewed)

Using VB6 i assume one can still program for years.
Though like VB3, we have no VB6 apps any more.

[Kev Peel]

It might be "yawwnn" to you, but to me all points are valid, and I noticed you skipped some of the more well known points.

MY opinion is VB still s***ks. You're welcome to it

[Edwin Knoppert]

Do not take it personal

[Chris Holbrook]

I know nothing of VB programming. Well hardly nothing.

WITH has saved me many hours of typing Pascal code, however, and I vote for it.

	    New ( NewInBatch );
	    with NewInBatch^ do begin
		BLRef       := SX.LRef;
		BAcct       := SX.Acct;
		BDate       := SX.Date;
            end