Announcement

Collapse
No announcement yet.

BIG QUESTION, need answer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Rodney Hicks
    replied
    I don't know that I'm thick skinned, but I have been told I'm thick headed.

    I echo Stan's comment a few posts ago. I'm glad you've joined the crew.

    You're last paragraph shows that you possess a much deeper appreciation of working with others than some that have passed through. And some wit too. One of the handy tools for survival.

    Incidentally, when I write my book, I want you to forget my earlier comments on authors.

    On a slightly different note, just as an interesting test of the content(quantity) in this forum, one five page(forum) thread turned into a thread of 73 printed pages. This the result of expanded code boxes of course.

    We have written a lot, and perusing the full forum yields some real gems, and I think we've forgotten things we had earlier established. Or accepted that what we established had to be set aside in the interest of progress. Globals were not the only thing that have been beaten.

    With regard to the documentation of the converter, two things: Is the converter going to be released as source code/compiled code/documentation?
    or as compiled code/documentation?
    I think most users would transfer the original zip package containing whatever we put into it. We don't want to go the nag screen route, I'm sure.
    I think feedback from version one will help by showing us what we need to change, add, or accommodate, and we will manage a more user friendly version 2 I'm sure.

    Since this is likely my last post until Monday, good weekend all.

    Leave a comment:


  • John R. Heathcote
    replied
    Rod,

    When you think about it, anything with Global scope can be misused, including %EQUATES. (ie. using the wrong equate at the inopportune time.) But these same books don't mention this particular item that can cause freaky hard to find errors in source code. (I been down that road, and let me tell you, it's not just a day trip.)
    So true, so true, and just so you know, I've been down that road too. You're right, it's not a fun journey to take.

    Globals are a tool, like all the tools, to be used when appropriate.
    I agree. I guess what I was trying to say is we shouldn't give the end user the impression (or encourage, if you prefer?) that all problems can be solved with liberal use of GLOBAL variables when they use our converter. The new user must understand the use of GLOBAL variables within the conversion process is the only practical way to convert certain sections of VB to PB. Obviously this could be explained in the documentation, as well as online informational messages to the user.

    The real issue here is what is the level of programming experience does the new PB user have? Since they are new to PB that experience level would be close to 25 on a scale of 1 to 100. OTOH I've met plenty of supposedly good VB programmers, just ask them, who were not all that great practicing their craft and this lack of talent transfers over to PB. While I think most VB programmers can quickly grasp PB concepts (Stan is a good example) you will always find those who will unfairly judge PB by what the converter does, or doesn't do. I would hate for Mr. Zale to lose customers and potential sales because of something I did.

    Having said all of this, I would tend to agree with you Rod that we are probably pretty close to agreement on GLOBALs. I think I've beat this horse senseless, next topic please.

    BTW, it's refreshing that you folks have thick skins, and because of that, it makes giving opinions (rants?) that much easier for me. I'm very appreciative that you don't take what I say personally. I found in my career at CDOT that most folks did not speak up, and if you spoke up management always took what you said personally, consequently a lot of bad decisions and policies were implemented because nobody said anything to the contrary. So that is why I speak my mind, get the idea on the table, generate the discussion, and if I get voted down, well that's ok with me too. You win some, you lose some.

    Leave a comment:


  • Rodney Hicks
    replied
    John,
    I don't really think that we're all that far apart on the issue of Globals.
    There's no question GLOBAL variables will get the job done here, but every programming book I've ever read says you should keep GLOBALS to a bare minimum. And according to these same texts the over use of GLOBAL variables is one of many signs you have a potential design flaw in your application.
    When you think about it, anything with Global scope can be misused, including %EQUATES. (ie. using the wrong equate at the inopportune time.) But these same books don't mention this particular item that can cause freaky hard to find errors in source code. (I been down that road, and let me tell you, it's not just a day trip.)

    IMO those authors that call the use of Globals a bad programming practice are either reciting rhetoric or bad programmers, hence they become authors. Globals are a tool, like all the tools, to be used when appropriate.

    That said, trying to keep as many variables Local in scope for this project is decidedly the wise way to go, since neither we as the builders, nor PB as the compiler can possibly know the original programmer's bent.

    I think if we stick to the Level 1 conversions like we have talked about it will work for PB 8 and 9.
    Good point. In fact the upcoming PB 9 shouldn't hold us back at all.

    Leave a comment:


  • StanHelton
    replied
    Welcome back Brian.

    My perception:

    I think we're talking about 2 main issues here. The easy one is whether to use PB 9 for vb2pb itself. I would be willing to vote for a slight delay in release date, say 2 weeks, maybe 3, in order to take advantage of the new compiler. The only question is, can we all get a copy of the new compiler in time? If the answer to that is really 'no', then vb2pb v1 will have to be done in PB 8 by default.

    The second main issue is: Does vb2pb v1 do PB 8 or PB 9 or try to do both? PB Inc says it may be 2 weeks to actual v9 delivery for this community. I can only guess at how long it will take to get into the user community at large. Although the new compiler looks beautiful to me, I wonder about trying to support it before we're up to speed on it ourselves. I can't help thinking we should drive on aimed at v8.04 for now. Almost everything we have so far will work in both compilers as vb2pb code, if I read the manual right. I just don't have a feel for how much of the output could be easily upgraded to work in v9 with v2 of VB2PB.

    That said, I agree with Brian on supporting PB9 over PB8 with the caveat that release 1 won't be robust enough to support the advanced features of either.

    Other points in the discussion:

    John is correct when he says the vb2pb.exe will get out into the wild without it's documentation. This happened more often than not with my own shareware back in the day. Some sort of built-in warning about v1 limitations should be included. Perhaps a disclaimer with an Invitation to Contact the Team? That's just off the top of my head. :coffee3: I've got some space on my site that could be used as a distribution point if we can't set something up with PB Inc., someplace where users can go to see VB2PB specific info.

    Regarding PBForms:

    I've been working under assumption that it would be required for v1. John brings up a valid point about end user frustration. OTOH, it may be too late to change that decision for v1. I'm undecided, but leaning toward keeping the requirement for the first release only.

    Regarding DDT:

    Well, what can I say. I like DDT, and v9 looks great to me. It's certainly right to talk about including our own forms conversion module for release 2, even if PB Inc updates PBForms. Same arguments apply here as applied for including our own edit control. Since we haven't been planning in this direction I'm not sure there's time to do it all for release 1.

    Regarding GLOBALS:

    I have no problem with using GLOBALS (Remember GW where everything was global?), but it is easier to break code using globals from anywhere in the code. If we're still supporting VB2PB 2 years from now, that could become an issue as more programmers work on the source. My opinion is only where necessary and well documented.

    Leave a comment:


  • John R. Heathcote
    replied
    Rod,

    It makes no sense not to take advantage of the amount of code already converted by PB itself.
    I tend to agree with you here, it makes no sense to reinvent the wheel, but we at least should warn the user that conversion "requires" PBForms. Perhaps this could be done during installation and possibly a warning message to the user every month or so.

    Considering what the converter is going to cost them, it is not unreasonable, IMO.
    It's not the cost that bothers me, its the fact that the converter may eventually be distributed from who knows where because it's been copied over and over, and when that happens things usually get left out in the distro.

    When the user attempts to run the converter it bombs, doesn't quite get the job done, which IMO leaves the new PB user worse off than he was before, because he now has a bunch of garbaged VB code with no where to go. And this will happen, unfortunately. I'm just suggesting that we need to give the user a point of departure, even if it is only a warning message, that they need to do X, Y, and Z to complete the process and this functionality should be part of the converter itself.

    I don't understand why use of globals in this instance is bad PB programming practice, have I forgotten something? If the use of globals is the most secure way of getting the job done, why not?
    The (over) use of globals can cause insidious bugs to creep into your application if you are not careful, and sometimes these bugs can be hard to track down because, theoretically, any procedure in your application can change the value of any global variable. There's no question GLOBAL variables will get the job done here, but every programming book I've ever read says you should keep GLOBALS to a bare minimum. And according to these same texts the over use of GLOBAL variables is one of many signs you have a potential design flaw in your application.

    I'm not saying that the user should not use GLOBAL variables under any circumstances. I use GLOBALS in my apps all the time, but I tend to keep their intended use very restrictive, such as a handle to a dialog box or windows control. I just don't want new PB users to get into the lazy habit of overusing GLOBAL variables to handle what should be essentially performed by a well designed software procedure/module.

    Perhaps I overstated my opposition to GLOBALS, how about a message that "suggests" to the new user to use LOCAL variables scoped to the procedure, passed as parameters if necessary, if and wherever possible, and save GLOBALS for system wide control, like AutoCAD system variables if you know what they are.

    I think the converter should be developed with PB9.
    I have no problem with that, the question is when can we get our copies and begin coding? Ordered mine yesterday and the e-mail PowerBasic sent me stated there would be a delay of at least 14 days due to the heavy demand for this new toy. I think Mr. Zale and company are doing everything they can to help allieviate the situation, but for right now we will just have to wait.

    Brian,

    I would like to skip PB 8 and just support VB2PB9. But, we started with 8 and there are some that won't upgrade.
    I think if we stick to the Level 1 conversions like we have talked about it will work for PB 8 and 9. Although the new commands, statements and functions in PB 9 look very promising it will take a bit of time to fully comprehend their true functionality, particularly when attempting to convert one programming language to another. I would prefer we all gain some experience with our new toys before we jump into the PB 9.0 waters with both feet.

    On the other hand, will new users to PB be able to get PB8 and will they want to?
    I think most folks who have posted in these forums will upgrade, so will other customers once they find out PB does objects at PB speed, that fact alone is worth the very modest price of the compiler, IMO.

    Leave a comment:


  • Rodney Hicks
    replied
    what is the user supposed to do if they do NOT have PBForms?
    We had already decided that PBForms was going to be a necessary ingredient to the job and possession of was required, at the same time that we decided to start with the PBForms handling the .frm files, It makes no sense not to take advantage of the amount of code already converted by PB itself.

    "WARNING - YOU NEED PBFORMS TO CONVERT YOUR VB FORMS TO PB!"
    Considering what the converter is going to cost them, it is not unreasonable, IMO.


    I also think that those with a lot of code to convert will recognize the savings in time that will offset the purchase price, not to mention what it does to the learning curve. PBForms has got many a programmer more comfortable with PB, whether they came from other languages or were just beginning.

    I think the converter should be developed with PB9.
    With regards to the output file being PB 8 or PB 9, I guess a user option that defaults to PB 9? This would mean a "|PB9|" in the terms so the converter could distinguish, and is readily doable.

    with a suitable warning, of course, that the use of GLOBAL variables in this particular instance is a bad PB programming practice and why.
    I don't understand why use of globals in this instance is bad PB programming practice, have I forgotten something? If the use of globals is the most secure way of getting the job done, why not?

    I say get the product out the door
    My sentiments. We could worry ourselves to death about things that mean nothing to the ultimate users of the converter.

    Again, we should concentrate on those aspects of VB that will not work in PB under any circumstances.
    If I may add to that, "that are quick and easy to convert for the first release."

    Once we get the vehicle moving, we can start mowing down obstacles.

    Leave a comment:


  • Brian Chirgwin
    replied
    I would like to skip PB 8 and just support VB2PB9. But, we started with 8 and there are some that won't upgrade. On the other hand, will new users to PB be able to get PB8 and will they want to?

    I believe PB 9 helps with a lot of issues. I don't have it so I am not sure, but:
    • Each Form because it's own PB class
    • Each class becomes a PB class
    • Global module code becomes just PB code module
    • A PB 9 shell runs the application


    This isolates code in a similar way VB does. Someone coming from the VB environment might find PB 9 easier than PB 8.

    Since I don't have it, I can't confirm this and as stated it will take time to understand the PB 9 changes.

    I think the converter being written in PB 9 isn't a problem. Supporting output in PB 8 and/or 9 is the question.

    Originally posted by John R. Heathcote View Post
    Rod,

    Developing the converter in PB 9.0 is a two edged sword. While I agree that it would be nice to take advantage of all the new and really cool features of PB 9.0 when converting old VB code, what about the user that doesn't have 9.0 yet? If all they have is PB 8.04 then all of the nifty VB to PB 9.0 conversions won't do them a bit of good. Not trying to be negative here, but just playing devils advocate.

    Leave a comment:


  • John R. Heathcote
    replied
    Rod,

    Developing the converter in PB 9.0 is a two edged sword. While I agree that it would be nice to take advantage of all the new and really cool features of PB 9.0 when converting old VB code, what about the user that doesn't have 9.0 yet? If all they have is PB 8.04 then all of the nifty VB to PB 9.0 conversions won't do them a bit of good. Not trying to be negative here, but just playing devils advocate.

    IMHO if we develop in PB 9.0 we should probably convert to PB 8.04 standards, at least for the first version of the converter. Once PB 9.0 is more firmly established and used by the majority of PowerBASIC customers, then we can convert VB to PB 9.0. Does that make any sense?

    For the record I ordered my upgrade copies of PB 9.0 and PBCC 5.0 yesterday, yeah I splurged, felt good too.

    In light of the recent development with PB 9, I suggest that we carry on with and concentrate more on using the DDT style.
    OK.

    By passing the *.frm files through PBForms first, a considerable amount of conversion is already done for us, though the converter will have to parse to pick up the things that were not supported in DDT at the time.
    This does bring up a nagging question, what is the user supposed to do if they do NOT have PBForms? Obviously the converter would have to inform the user that, perhaps, a major portion of their VB project could not be converted without PBForms. Is there another way to convert VB forms without the use of PBForms? Personally, I think we should provide some rudimentary VB form conversions for the user as they will be expecting our converter to work, and be very put off by a warning message like:

    "WARNING - YOU NEED PBFORMS TO CONVERT YOUR VB FORMS TO PB!"

    Bad PR.

    While I know I shouldn't go out on a limb without a safety net, I am going to state that I suspect that a PBForms 2 may not be far away. Just in time for converter version 2??
    I agree, can't imagine Mr. Zale releasing a major upgrade to the PB compilers without considering his supplemental development tools in the upgrade path too.

    DDT and SDK can be mixed, there are plenty of examples of it in the fora, one just has to be judicious, and in our case, make the converter judicious.
    I was thinking more along the lines of converter source code maintenance rather than if it is doable or not, that's all.

    From what you've seen so far with regards to the PB 9, how do you feel about the Scope issue we were looking at a few weeks ago?
    I think the problem is still there unless one were to convert a specific VB module to a PB object. While this may be possible, I certainly don't think it is desirable as it changes the intent of the source code and that is an issue I do not wish to tackle. So we may be stuck with using GLOBAL variables for VB module level code for the time being, with a suitable warning, of course, that the use of GLOBAL variables in this particular instance is a bad PB programming practice and why.

    With regard to type identifier...
    It would be nice if the converter took care of this issue, but if it comes down to getting the converter out the door and into the users hands, or delaying the release to implement the replacement of type identifiers, I say get the product out the door. Type identifiers will still compile even under PB 9.0. Again, we should concentrate on those aspects of VB that will not work in PB under any circumstances.

    Leave a comment:


  • Rodney Hicks
    replied
    I'm leaning towards using PB 9 entirely rather than some of each. I think the changes in PB 9 from PB 8 are worth the jump, not to mention that having the converter convert code to PB 9 standards will make the project a lot easier, once we all get our heads around it. A lot of stuff that has been figured out will be just as useful in either version. And it will help us all pick up the interesting nuances of PB 9 a lot quicker.

    Strangely enough, this issue is one of the reasons that I was reluctant to use any other products for creating the converter. Just like our converter has to be PB 9 compatible now, so do all the other products in order to get full value of PB 9, thus working with another product we may not be able to use full value of the new software.

    Leave a comment:


  • Brian Chirgwin
    replied
    PB 8 or PB 9 support?

    I go on vacation and upon my return things have changed.

    Do we continue to support PB 8? I'm not sure, I will be moving to version 9. I think the VB2PB converter will be written in PB 9.

    If we do support PB8, we may be able to use PB9 COM features to make the support easier. i.e A set of Objects, COM classes (created in PB9) that PB8 can use to implement VB classes easier in PB 8.

    So, do we support v8 or jump to supporting v9?


    Originally posted by StanHelton View Post
    Rod, John,

    I plan to order my copy of PB 9 & CC 5 first thing in the morning.

    How does this new release affect your perception of this project?

    I think we should continue.

    Stan

    Leave a comment:


  • Rodney Hicks
    replied
    Gentlemen,
    I think we decided to make PBForms a requirement to simplify the dialog creation tasks.
    We did, but with the caveat, perhaps unmentioned at the time in my delight at discovering(okay, being advised of) this aspect of PBForms, that the resulting code converted by PBForms is DDT style.

    In light of the recent development with PB 9, I suggest that we carry on with and concentrate more on using the DDT style. I'm anticipating less use of the SDK to some extent with the advent of PB 9. That most user's of our product will likely be using PB 9, while not a given, is a logical assumption on my part.

    By passing the *.frm files through PBForms first, a considerable amount of conversion is already done for us, though the converter will have to parse to pick up the things that were not supported in DDT at the time.

    While I know I shouldn't go out on a limb without a safety net, I am going to state that I suspect that a PBForms 2 may not be far away. Just in time for converter version 2??

    DDT and SDK can be mixed, there are plenty of examples of it in the fora, one just has to be judicious, and in our case, make the converter judicious.

    Remember too, that version 1 was going to have some gaping holes, and MDI might have to be one of them, there are a few others that I think might or might not be shunted aside until later versions. Hooks, Printing, Coordinate Spaces, Device Contexts etc come to mind. In fact somewhere in this forum there was a list of things that we were going to get into version 1 because they were likely to be the most common items the converter was going to encounter. I'll have to find that.

    While it took them years to make VB as bad as it got, we haven't years to solve all the problems they created. Some of the VB code, will be best rewritten by hand anyhow, simply because of the drastic improvement when done PB style, which of course teaches the ex VB programmer PB style programming.

    With regard to type identifier, while the PB manual(p143) may have errors in it, I don't think so in this regard and this should be able to be handled by the converter as part of the normal vbterm=pbterm conversion process, with VARIANTs and some CONSTs maybe needing some extra help. The #$% jargon wouldn't get placed in the converter output, because the converter would be converting to the suggested standards.(That looks like a censored sentence, doesn't it?)

    From what you've seen so far with regards to the PB 9, how do you feel about the Scope issue we were looking at a few weeks ago?

    I will be adding to the your file Stan over the weekend, time permitting, since everything needed should be in my laptop already.

    that we are all here to drain the swamp
    I like that.

    Leave a comment:


  • John R. Heathcote
    replied
    Stan,

    I think we decided to make PBForms a requirement to simplify the dialog creation tasks. I'm not sure if that is still a valid reason, but I tend to think so.
    Well, this really depends on how we want to set up the converter. If we have the main dialog containing the Scintilla edit control, a dialog for the "Command Center" that would comprise about 75% of all the dialog functionality we may need, couldn't that be handled using SDK? OTOH the remaining 25% dialog functionality would have to be added and I suppose it wouldn't be a good idea to mix SDK and DDT would it?

    I do have PBForms, but it doesn't seem to handle MDI, at least I couldn't find it. If true, the MDI aspects of an editor will have to be coded by hand anyway. I will investigate the difficulty here and get back to you.

    Sounds like something for the vb2pb Command Language. I'm beginning to think the command line interface won't be too much trouble to make.
    Type identifier conversion functionality could also be handled with some sort of preprogrammed routine. The issue here is, do we really need to address type identifier conversion, or do we leave this alone and let the user determine if they want to remove type id's at their convenience? After all, type identifiers will not necessarily cause the resulting converted source code to fail the compile process, the only caveat at the present time being the warning Mr. Zale states in the help document about type identifiers being deprecated in the future. Having said that, it does make sense to offer the user the opportunity to get their old VB code up to current recommended PB coding standards. I think this is one of those issues where we should offer the user the capability of revising type identifiers if they want to.

    A possible command to do this would be:

    Code:
    ''//REPLACE ON ANY "!#$%&" WITH ""
    ''//REPLACE OFF
    To borrow from PB syntax.

    Just in case I didn't say it before: Thanks for joining the project.
    I'm enjoying myself, it is nice to work with you and Rod and everyone else that understands the true nature of the problem, are willing to look at all ideas with an open mind, but all the while keeping an eye on the fact (with gentle prodding once in a while) that we are all here to drain the swamp. Yup, it's fun.

    Leave a comment:


  • StanHelton
    replied
    Originally posted by John R. Heathcote View Post
    ...
    Just for my own edification when and where does my app hang up. Could be this is a Firefly problem, OTOH could also be a Scintilla problem....

    Let me run it again tonight and make notes this time as I go. Feedback in the morning.

    ...
    Actually it is not any more difficult to use in PB IDE environment than it was to implement in Firefly... but I could switch over to SDK or PBForms (I think I still have it) if need be.
    Okay, so it's just a matter of me learning the Scintilla API. I can do that. I think we decided to make PBForms a requirement to simplify the dialog creation tasks. I'm not sure if that is still a valid reason, but I tend to think so.

    I based much of my Scintilla application on Jose Roca's initial source code editor "PBSCITE" ...
    I would like to get Jose's input on this issue just to cover all of our bases.
    Why don't you ask him about it while I spend a day or so learning the API?

    ...
    OTOH animation lets the user know something is happening which can be quite reassuring, one of those user issues.
    All the feedback I've gotten says the user won't care if it takes 2 minutes, 2 hours, or even 2 days. Animation is good.

    ...
    all we have to do to make this work in PB IDE ...
    Works for me.

    ...
    BTW I deliberately chose to comment out VB changes so the user can see the differences between VB and PB, take every opportunity to educate the new PB user, however, this functionality could also be a user defined option, but I think it should be a default.
    Once I remembered that you had set it up that way, I found this feature useful in my test runs.

    No problems with your UNDO/REDO. We want it to play nice on most PCs.

    ...
    One other issue ...
    update (upgrade?) the original VB code to the recommendations made in the PB help file concerning coding ...
    Sounds like something for the vb2pb Command Language. I'm beginning to think the command line interface won't be too much trouble to make.

    All good ideas. We're making some serious progress now. Just in case I didn't say it before: Thanks for joining the project.

    Stan

    Leave a comment:


  • John R. Heathcote
    replied
    Stan,

    Glad you like the concept. I think one of my strengths is conceptual design, a trait shared by many left-handed individuals.

    On my machine it hangs in a couple of places, but you said this is concept demo, so I'm not worried about that.
    Just for my own edification when and where does my app hang up. Could be this is a Firefly problem, OTOH could also be a Scintilla problem. Might be one of those cumbersome aspects that I mentioned earlier. If this is the case we would need to trace this down it might be solved by using other Scintilla commands.

    Since I don't do FireFly, how should we proceed here? I'm not clear on how to use the SciLexer.DLL in a PB IDE environment. The API calls are clear enough, but I will be working with a slight learning curve.
    Actually it is not any more difficult to use in PB IDE environment than it was to implement in Firefly, one does not depend on the other. I used Firefly as it was what I was familiar with for dialog box design, but I could switch over to SDK or PBForms (I think I still have it) if need be.

    I based much of my Scintilla application on Jose Roca's initial source code editor "PBSCITE" which is available on POFFS or the PB Source Code forum and is a SDK app. PBSCITE is Jose's first attempt (and a very good one I might add) at using the Scintill editor control and what eventually became his SED editor, so we could use this app as the basis for implementing our converter. So the real credit and kudos should go to Jose. I would like to get Jose's input on this issue just to cover all of our bases.

    Personally I think I may have gone a little overboard with the animation on most of my commands, which can be fixed by using other Scintilla commands to read the file. If you don't want the animation effect while reading the file and making the conversions Scintilla can be quite quick. OTOH animation lets the user know something is happening which can be quite reassuring, one of those user issues.

    Basically, all we have to do to make this work in PB IDE (or any other PB editor for that matter) is to read a line(s) in Scintilla, pass the line(s) to the Tokenizer for processing along with a flag to determine if the original line has been changed, pass the revised source code line(s) back to Scintilla and update the display, if necessary. BTW I deliberately chose to comment out VB changes so the user can see the differences between VB and PB, take every opportunity to educate the new PB user, however, this functionality could also be a user defined option, but I think it should be a default.

    The Scintilla control has an UNDO/REDO feature, but it is based on available memory which can vary from system to system. That is why I chose to implement my own version of the UNDO feature by using incremental saves. Perhaps we can use both.

    One other issue I was thinking about is to update (upgrade?) the original VB code to the recommendations made in the PB help file concerning coding, e.g., use the "OPTIONAL" key word for "[]" in the argument list, specify the data TYPE instead of using the type identifier, etc. Perhaps this functionality could be addressed as a series of (RE)FORMAT commands.

    Just a thought.

    Leave a comment:


  • John R. Heathcote
    replied
    Rod,

    On a different note, on Friday I've got to disappear for a few days again because of a death in the family. Should be back up Monday sometime.
    My sincere condolences to you and your family. I will keep a good thought while you are away. Please take all the time you need.

    Leave a comment:


  • StanHelton
    replied
    Originally posted by John R. Heathcote View Post
    ...
    My Scintilla app fills some of Rod's suggestions that we convert line by line, by procedure, or entire file. This functionality is tied in with the "F5" and "F8" keys, the same ones used by VB and PB for the same purpose. The user can set predefined book marks to accomplish limited conversion as well. Be sure to read the README.doc file first as it explains some things.

    Thanks.
    John,

    I like the concept. The Scintilla editor may be just what we need. My only trouble is that I don't use FireFly, so I have difficulty with some of the generated code.

    OTOH, I AM impressed. Your app does exactly what I was trying to do with my little editor window. Will save quite a bit of work. Maybe we won't have to delay the release for too many days after all.

    I've run the app on some of my VB code and it looks good (better than mine!). On my machine it hangs in a couple of places, but you said this is concept demo, so I'm not worried about that.

    I've reviewed the Scintilla docs and the doc you wrote. I think you've found a solution to the editor issue. So....

    Since I don't do FireFly, how should we proceed here? I'm not clear on how to use the SciLexer.DLL in a PB IDE environment. The API calls are clear enough, but I will be working with a slight learning curve.

    Basically: I like it!

    Stan

    Leave a comment:


  • StanHelton
    replied
    Originally posted by John R. Heathcote View Post
    ...
    After having just taken a shower and letting my mind concentrate on the CONVERTER command, I was struck by the thought (not to mention getting soap in my eyes) that we could have our own converter command language to take care of all sorts of special conversion problems. Version 2.0 is looking better and stronger all the time.
    Like I said, a Cadillac! Loaded.

    ... VB2PB should be as forgiving and nondestructive as we can possibly code it.
    Definately.

    Looked through the VBTERMS file, there's alot there, will have to give the contents some additional thought. Will get back to you on this.
    Rod noted that it's only half the dictionary. I'm thinking we could use it as is, just writing our code to use the plain text file. Text file is easier to update later if we need to.


    Originally posted by Rodney Hicks View Post
    Bob Zale's thread "Be the first on your block..." was started at 2:21, my confirmation of order was received at 3:19. Not quick enough to be first, but I'm in line waiting for delivery via the mail(included manual) so I won't be running PB 9 for a wee while. I won't be ordering PBCC for a while, dollars being what they are.
    Yeah. Cash flow being what it is I had to wait til today to place my order. But I'm right behind you (well, maybe a few hundred spots back) in line.

    ...
    I'm glad you guys liked the CONVERTER ON/OFF idea, there may be other codes we could use in similar fashion. Prepending the comment characters was a good idea although I would think that anyone converting code would be using a second copy of the code to convert, maintaining the original in original form for nostalgia's sake.
    I'm thinking this is the first command in our vb2pb conversion script language. (Me? Grandios? noooooo.....)


    I have looked at the file, and I am wondering, have been for a while, if there isn't such a monster already in existence, perhaps in slightly different format, elsewhere in the PB universe. It might not hurt to inquire formally somehow.
    Will do.

    I had been running into difficulty with the constants, finding the appropriate constant name/value/purpose and then checking against the SDK for clarification. The same is going to happen with the Methods/Properties/Events etc. terms I believe(no SDK for clarification though).
    Yeah, I noticed that too. Down lower in the file is a list of constants. Are those at all helpful?

    The layout of your file is good and easy to work with. You might want to give me some advice on how you want me to work with that, because it is half of the terms job in one place, and I assume you want the other half in the same place. Same format? term appended to VB term? What about other essential info?
    Just off the top of my head, include a double pipe (||) or an elipsis (~) to separate PB from VB on the same line and use the same format? Feel free to modify the format any way you see fit to accommodate essential info. The only thing is I think the text file will be easier to work with, modify, update, change, burn, spill coffee on, etc, etc.

    On a different note, on Friday I've got to disappear for a few days again because of a death in the family. Should be back up Monday sometime.
    Be well and safe on your trip. Sorry for your loss.

    Stan

    Leave a comment:


  • Rodney Hicks
    replied
    Bob Zale's thread "Be the first on your block..." was started at 2:21, my confirmation of order was received at 3:19. Not quick enough to be first, but I'm in line waiting for delivery via the mail(included manual) so I won't be running PB 9 for a wee while. I won't be ordering PBCC for a while, dollars being what they are.

    I'm glad you guys liked the CONVERTER ON/OFF idea, there may be other codes we could use in similar fashion. Prepending the comment characters was a good idea although I would think that anyone converting code would be using a second copy of the code to convert, maintaining the original in original form for nostalgia's sake.

    I have looked at the file, and I am wondering, have been for a while, if there isn't such a monster already in existence, perhaps in slightly different format, elsewhere in the PB universe. It might not hurt to inquire formally somehow.

    I had been running into difficulty with the constants, finding the appropriate constant name/value/purpose and then checking against the SDK for clarification. The same is going to happen with the Methods/Properties/Events etc. terms I believe(no SDK for clarification though).

    The layout of your file is good and easy to work with. You might want to give me some advice on how you want me to work with that, because it is half of the terms job in one place, and I assume you want the other half in the same place. Same format? term appended to VB term? What about other essential info?

    On a different note, on Friday I've got to disappear for a few days again because of a death in the family. Should be back up Monday sometime.
    Last edited by Rodney Hicks; 13 Aug 2008, 12:41 PM.

    Leave a comment:


  • John R. Heathcote
    replied
    Stan,

    Definition for CONVERTER ON/OFF directive:
    Works for me.

    After having just taken a shower and letting my mind concentrate on the CONVERTER command, I was struck by the thought (not to mention getting soap in my eyes) that we could have our own converter command language to take care of all sorts of special conversion problems. Version 2.0 is looking better and stronger all the time.

    I'm sure you and Rod have thought of this, but just for the record I will state it too, VB2PB should be as forgiving and nondestructive as we can possibly code it.

    Looked through the VBTERMS file, there's alot there, will have to give the contents some additional thought. Will get back to you on this.

    I can see right now my association with you good folks is going to cost me some money 'cause I'm off to buy PB 9.0 too.

    Leave a comment:


  • StanHelton
    replied
    Definition for CONVERTER ON/OFF directive:

    CONVERTER ON/OFF

    syntax:
    ''//CONVERTER [ON | OFF]

    ''// special obnoxious string to cue vb2pb without interfering with compiler. Because of leading single quote compiler treats this line as a comment.

    CONVERTER command string to vb2pb

    ON vb2pb starts converting with the next line of code

    OFF vb2pb stops converting until EOF or next CONVERTER ON, default setting at beginning of conversion process.

    Comment: While it is recommended to remove this command from code you intend to compile in VB6, the leading single quote makes removing the command optional. Note that the default value is OFF. That means at least one CONVERTER ON command line should be placed into your code. If you wish to process the entire file place this command before all other code.
    I'm reading the Scintilla doc now.

    Leave a comment:

Working...
X