Pb 9.0

[StanHelton]

Hey Guys,
Heads up on the latest upgrade:

Bob moved me to the top of the list so we can start writing code specifically for PB 9.0.

Many thanks to Bob Zale.

Object conversion is a snap in this version. If you don't have the compiler, you can still write v9 code and I'll compile & test with feedback as quickly as possible.

Stan

[John R. Heathcote]

Stan,

I'm jealous!

Ordered my PB 9.0 and PBCC 5.0 a while back still haven't heard anything from PowerBASIC yet. Keep hoping today's the day.

[StanHelton]

Should be sooner rather than later, John. That hurricane is turning out to be less than they expected. Still a big storm, but it's only a Tropical Storm.

I would say I'm sorry, but I'm not really. This thing is fantastic! And it compiles PB8 code. So far I've not had to make any significant changes other than the kind of stuff I do every time I compile: typos & minor syntax errors mostly from my poor typing skills.

Believe me, it will be worth it when you get it!

Stan

[Brian Chirgwin]

Stan,

Even though I don't have it yet, It looks like conversion of a VB6 COM Class to a PB9 Com class is just change of syntax. Is this what you are finding?

Brian

[StanHelton]

Brian,

Stan,

Even though I don't have it yet, It looks like conversion of a VB6 COM Class to a PB9 Com class is just change of syntax. Is this what you are finding?

Brian

Yes. I haven't encountered any problems here. There is a thread in the Programming With Objects forum that might be of interest, but no one else has reported any problems that I know of.

http://www.powerbasic.com/support/pbforums/showthread.php?t=38293

I'm watching that thread just in case something comes of it.

Stan

[John R. Heathcote]

Stan,

Not only PB 9.0 handling objects, but forward referencing too.

Can FUNCTIONs return a UDT? I read the online documentation about this and while no mention was made that FUNCTIONs couldn't return a UDT, the docs didn't specifically state they could return a UDT either.

So which is it?

[StanHelton]

John,

No luck on FUNCTIONS returning UDTs. On the other hand the IN, OUT, and INOUT keywords in the METHOD/END METHOD block are better than using a regular SUB.

Stan

[Rodney Hicks]

I will admit that I'd like PB9 for doing the dictionary just to verify the new features easier than checking the website help, but that would really be just procrastinating(which I'm good at). There aren't that many items that were in place that will change, it's mostly the new stuff.

That Bob moved you up the list is a good indication that we should do everything in PB 9 re our earlier discussion.

While I ordered physical delivery, I don't expect my order moved up, but as long as one of us has it we should be fine.

Has anyone thought of anything that got worse for our purposes instead of better with PB 9? I would be surprised if there was anything but I thought I'd ask.

[StanHelton]

I will admit that I'd like PB9 for doing the dictionary just to verify the new features easier than checking the website help, but that would really be just procrastinating(which I'm good at). There aren't that many items that were in place that will change, it's mostly the new stuff.

That Bob moved you up the list is a good indication that we should do everything in PB 9 re our earlier discussion.

While I ordered physical delivery, I don't expect my order moved up, but as long as one of us has it we should be fine.

Has anyone thought of anything that got worse for our purposes instead of better with PB 9? I would be surprised if there was anything but I thought I'd ask.

I've just finished running all my PB8 code through pb9. It all compiled without any problems. I had to play with the CONTROL SET OPTION syntax on one of them, but that turned out to be my typing mistake in the original.

I try to use the simplest syntax that gets the job done. I guess that was a good thing, since everything I've got compiles in pb9.

Just had a thought -- going to try John's Scintilla app in the new compiler ...
I'll let you know ...

[StanHelton]

John,

Your application compiles fine in pb9. Yay again to Bob for backwards compatibility to pb8 !!

Stan

[StanHelton]

Rod, John, Brian,

The more I work with this new compiler, the more I think maybe we should just make VB2PB go to pb9 code.

We won't have to change code we've already written, well, I haven't had to change anything.

I think the end-user will be a lot more satisfied with pb9 than pb8. The object implementation is smooth. We can get native object functionality without a procedural simulator.

Now that I'm actually working with it, I'm rethinking whether we should target pb8 after all.

Sorry to be so wishy-washy at this late stage, but you guys will understand when you get your hands on this.

I've got to run out for a service call right now. I'll check back later this afternoon.

Stan

[Rodney Hicks]

The more I work with this new compiler, the more I think maybe we should just make VB2PB go to pb9 code.

I'm glad you're coming to this. I think that making the converter for PB 8.04 limits what we can do even at this stage of the game. PB 9 has so much more to offer anyone that is converting code from VB and those are our target. Plus we may be able to get more into the first version than originally intended.

[John R. Heathcote]

Stan, Rod, and Brian,

Ok I'll offer my $0.02 too.

I guess I don't have a problem writing our converter for PB 9.0 as it sounds like 9.0 solves many conversion problems.

I do have to play devils advocate here just to let you all know that not every PB customer will move up to PB 9.0 right away. If we write VB2PB to specifically handle PB 9.0 then many of our (and potential PowerBASIC) customers will be put off by not having conversion capabilities for 8.x. IMHO this is a negative which we could avoid by supporting, maybe in a limited fashion, PB 8.x.

These are my thoughts only and whatever the group wishes to do I will support.

Stan,

Glad my Scintilla app compiled and ran OK under PB 9.0, most gratifying.

BTW, I've been giving the CCL (Converter Command Language) some serious thought, I know I should be concentrating on other things, but CCL is one of those nagging (in a good way) concepts that I just can't leave alone. The more I think about it the more I realize there is some real power and flexibility in CCL.

Wish I could take credit for this idea, but the credit goes to Rod, well done!

[Rodney Hicks]

I agree that not everyone will purchase PB 9 right away, however, I do think that any ex VBers will upgrade as soon as possible since even without our converter PB 9 solves several issues for them.
But on the off chance that there are some being left behind we could simply do as suggested earlier, have a %PB8/%PB9 flag and in our dict file specify when PB 9 is required( the new features) and let the user know they got some programming to do. To make it easy on us, that flag could be the last piped field.
While we're at it, perhaps someone should find some bag pipe music to use as our theme since we're going to be acting like Scots and piping in the fields.

If we go this way, we should advise those using PB 8 that future versions of the converter may not support PB 8, like a nag screen.

[John R. Heathcote]

Rod,

But on the off chance that there are some being left behind we could simply do as suggested earlier, have a %PB8/%PB9 flag and in our dict file specify when PB 9 is required( the new features) and let the user know they got some programming to do. To make it easy on us, that flag could be the last piped field.

Works for me, again, I was just playing devils advocate.

While we're at it, perhaps someone should find some bag pipe music to use as our theme since we're going to be acting like Scots and piping in the fields.

Well being part Scotsman and Cherokee Indian (now there's a pair to draw to) I guess I would be elected to play the pipes, but I warn you I do not have the legs to appear in a kilt.

If we go this way, we should advise those using PB 8 that future versions of the converter may not support PB 8, like a nag screen.

I think we should limit support for Pb 8.x to version 1, maybe version 2, but drop 8.x support after that.

[StanHelton]

Excellent discussion!

I'm glad you're coming to this. I think that making the converter for PB 8.04 limits what we can do .... PB 9 has so much more to offer anyone that is converting code from VB ...

Sometimes I let myself get a bit too concrete. Should have known Bob and PBinc wouldn't let us down at all.

...
it sounds like 9.0 solves many conversion problems. ...

Yep.

I do have to play devils advocate here just to let you all know that not every PB customer will move up to PB 9.0 right away. If we write VB2PB to specifically handle PB 9.0 then many of our (and potential PowerBASIC) customers will be put off by not having conversion capabilities for 8.x. IMHO this is a negative which we could avoid by supporting, maybe in a limited fashion, PB 8.x.

I like Rod's idea about the pb8/pb9 flag: since pb9 is backwards compatible, this would be easy to implement.

BTW, I've been giving the CCL (Converter Command Language) some serious thought... The more I think about it the more I realize there is some real power and flexibility in CCL.

... the credit goes to Rod, well done!

Well done, Rod! You're the best idea man I've worked with in a long time.

John, it sounds like a good idea to me. If you have some ideas on implementation, I say go with it.

...
on the off chance that there are some being left behind we could simply do as suggested earlier, have a %PB8/%PB9 flag and in our dict file specify when PB 9 is required( the new features) and let the user know they got some programming to do. To make it easy on us, that flag could be the last piped field.

Sound good to me! Will noting new pb9 features slow down development on the dict file?

... perhaps someone should find some bag pipe music to use as our theme since we're going to be acting like Scots and piping in the fields.

If we go this way, we should advise those using PB 8 that future versions of the converter may not support PB 8, like a nag screen.

Hmmmm. Loch Lommond? Danny Boy? Background theme for the splash screen and the nag screens?

...
Well being part Scotsman and Cherokee Indian (now there's a pair to draw to) I guess I would be elected to play the pipes, but I warn you I do not have the legs to appear in a kilt.

If we get together and make a PR shot of all of us in kilts, you just might win the contest.

I think we should limit support for Pb 8.x to version 1, maybe version 2, but drop 8.x support after that.

This part sounds unanimous to me. We had decided to put most of the Object stuff on the back burner for v2 anyway. I think a little more work and I'll have a passable (with nag screen, of course) simulator for pb8. Letting the VB Refugees know that there is pb9 would be a good promo for us and PBinc both!

Stan

[Rodney Hicks]

Seriously guys, I was only joking about the bag pipes!!!

If we get together and make a PR shot of all of us in kilts, you just might win the contest.

I don't think I have the required attributes under a kilt to wear one.

[StanHelton]

Seriously guys, I was only joking about the bag pipes!!!



I don't think I have the required attributes under a kilt to wear one.

I dunno. The idea of bagpipes is just campy enough to work.

Back in my army days I worked with a highlands regiment for awhile. I was told all you need to wear a kilt is a 12 inch dirk strapped to your calf and an attitude that makes everyone think you like to use it on people who ask questions about the kilt.

[Rodney Hicks]

I dunno. The idea of bagpipes is just campy enough to work.

Strangely enough, you're right on this. Kilts are just enough visually strange(yet everyone has seen them) to attract a second glance, but worn by gentlemen of power.

Although putting me in one is likely to put me off kilter.

I know, bad pun.

[John R. Heathcote]

Rod and Stan,

Sounds like you guys are getting too carried away with this bag pipe/kilt stuff. I think we ought recognize the Scots for their one contribution to western civilization; golf.

I am rewriting my Scintilla app to use DDT instead of Firefly, this way we will eventually have an editor framework to add conversion commands and functionality. The app is based on Jose Roca's PBSCITE.bas example (as was the Firefly example), but is being reorganized somewhat to help in code maintenance, assuming we want to use Scintilla. Porting my Firefly code over to DDT is not too much of a problem as most of the functionality is found in source code modules which contained neither Firefly or DDT stuff.

I tried to convert PBSCITE.BAS to DDT, but I quickly found out that DDT does not handle MDI that well. Although it is not impossible to handle MDI under DDT, POFFS has several examples on how to do this, the gyrations one must preform to make MDI work obsfucates the straightforward approach of SDK. So the initial editor startup is SDK, but there are other forms that are DDT and both seem to coexist quite well.

While I am reorganizing the editor code I am implementing some CCL just to get an idea how difficult the implementation will be. So far, the actual CCL commands are very easy to implement, of course this depends on the complexity of the command itself. I would suggest that any CCL command be very simple in nature, handling one maybe two processing issues.

I would also like to suggest that any CCL command be prefaced by a different set of obnoxious comment characters rather than "''//". The reason is I assume we will eventually remove, or at least give the user the opportunity to remove, those offending VB lines from the PB source code. If we preface CCL with the above comment characters we will remove CCL commands from the source as well which may be an unintended consequence. Since CCL is a different type of functionality/processing we should have a separate procedure for removing CCL. The obnoxious CCL comment characters I'm using are "''CCL".

Will keep you posted.