SourceCode Only

[John R. Heathcote]

Michael,

I am thinking it may or may NOT be a starting point for a new version down the road. Might be just something to get ideals from or something to laugh and point at.

I want you to know I never laugh at another person's code. I treat it as a learning experience, since all of you have far more experience coding with PB than I do. Remember, I'm just an old FORTRAN IV and FORTRAN 77 guy.

FWIW I did not ever use an editor for conversion stuff. VB straight to PB files. Makeddt - header and RC files in -Ready to use DDT code.

I would be interested in your concept myself.

[Michael Mayerhoffer]

Stan and John

I am sorry, I have a twisted sense of humor ..was my way of saying this is what I got and do as you please with it.

Mike,

One of the dormant cogs in my brain just kicked in. You've mentioned this before, but I didn't make the connection.

Is MakeDDT a standalone app? What I'm getting at is, could MakeDDT eliminate the need for the end user to own a copy of PBForms?

Stan

Visual Studio can take a VB Form and convert it to a header and script files (.h and .RC ) or you can make a dialog and generate the script files.

MakeDDT converts the Visual Studio version 6 script files from self made Dialogs or converted VB Forms into a ready to run DDT skeleton code. Long as they come from a Visual Studio... just add event code. PBForms does the same thing per say. One package.


Long story short the answer is no - the yes answer.. can be done .. been there done that...PB to VB converter, a quick looks says I have to re event the wheel. Not a big thing.

My answer is yes, I am guessing the answer to your next question.. ?

PS you can dowload makedtt from PB they do host it.

[Wayne Suite]

Question

So if I predict/read this write in order for the average user of PB to use this converter we are going to require them to OWN VISUAL STUIDO? Sounds awful expensive to me and your going to limit the number of persons who will see a use for this application unless the intent to begin with was to only have the advanced PB users be able to utilize this converter.

I am getting confused on the target audience for this VB2PB converter which is being developed. Please unconfuse me, I might have missed something since I just recently joined in the group...

TIA.
Wayne.

[Michael Mayerhoffer]

Wayne -The answer is no. VS is not needed could be an option for users.

guess starts here.

I think they are using PBForms and that might be the standard.

guess ends here.

The above rumbling from me is about MakeDDT and other stuff nothing to do with the project directly and this is what it boils down to....

I have volunteered to re invent the wheel on the Form conversion. Just waiting to hear back is this OK to-do.

My opinion and views are not official and non quotable.

Wayne = unconfused ?

[John R. Heathcote]

Wayne,

As Michael says:

I think they are using PBForms and that might be the standard.

Yes, this is the plan. It is my understanding PBForms does a good job converting VB forms.

[Wayne Suite]

Confusion - less

Thanks that helps.

[Wayne Suite]

Another Thought?

Just another thought I don't know if anyone has looked at it or not but occassionally I have tried the PBWINSPY and it seems to do a good job at replicating any forms you use it on vb6 or other, did/or has anyone also considered it? I do have the PBForms1.51 and think it is good also but I was just thinking that the PBWINSPY was trialware(maybe not correct) but for limited use is free.

[Michael Mayerhoffer]

Wayne,

could be used it is just not practical. Still have to create events and deal with different sources and naming conventions. Spend more time than necessary.


BTW PBWINSPY is freeware, the author is AWOL, I have not seen or heard from him in years


My opinion and views are not official and non quotable.

[Michael Mayerhoffer]

Update I have enough odds and ends to start a GUI converter ..alot of the keywords for control attributes missing.

So DDT or SDK ? Don't say both or you will make me cry !

3-10 days for a fair working model depends how much Murphy screws with my health.

Any suggestions comments ?

[StanHelton]

...
I am getting confused on the target audience for this VB2PB converter which is being developed. Please unconfuse me, I might have missed something since I just recently joined in the group...

Wayne,

Sorry for the confusion. Mike is new to the group as well and we have been discussing his ideas on GUI conversion. That's the discussion you fell into.

The target audience is anyone who wants to bring code over from VB6 into PBWin. In my mind that includes people who don't like dotNET, people who wish VB was still properly supported, and people who would like to try out PB because it's just so much better than that other stuff ... and ACTIVELY supported to boot!

In other words, a large group of programmers from beginners to hobbyists to professional developers, light heartedly referred to here as VBers and/or VB refugees.

The first release of VB2PB will be limited, but the development model we're using is based on incremental improvement with each release. We are counting on users and beta testers (you ) to help with the feedback, suggestions, discussion, planning, a little coding here and there, beer, pretzels.... Uh, sorry.

Update I have enough odds and ends to start a GUI converter ..alot of the keywords for control attributes missing.

So DDT or SDK ? Don't say both or you will make me cry !

3-10 days for a fair working model depends how much Murphy screws with my health.

Any suggestions comments ?

Mike,

DDT. VB2PB output should be DDT for version 1, so the generated code looks more or less the same. I think that once VBers begin to understand the differences in PB, DDT will be a bit more educational than SDK, not to mention more familiar.

Ok, I'll be quiet now. My eyelids are heavy and my pillow is calling my name.

Stan

[Rodney Hicks]

Once more I have returned to find out that even though I traveled far, I am much further behind.
Having traveled almost 4000 K since I last posted, I'm a bit exhausted, but I can see that you folks have been sorting things out.
I had hoped for a little time to work on my end of things, and I did get a little, but not as much as I was hoping for. (Murphy was on the road with me, so it was someone else 'helping' you folks, or it is as Michael said, he's a master of multi-tasking.)

Did you know that in the .INC files in the WinAPI subdirectory of PBWin 9.0 there are >26000 EQUATES? Daunting, yes, but I am taking steps to become undaunted.
Will have more to report in a few days.

Michael, your

I am sorry, I have a twisted sense of humor

apology is unwarranted and therefore unacceptable. A twisted sense of humour(sp) helps one to think outside the box, envelop, or whathaveyou. And you fit right in with Prime Minister Stan and the Minister of Obnoxia John. I don't at this time foresee a need to lighten myself of my twin portfolio of Minister of Finance and the Ministry of Silly Walks so John or Stan may stick you and Wayne with your own Ministries. There are, amongst others, Ministries of Conundrums, Brick Walls, Oblivia still available.

It has occurred to me that Murphy must live outside the box as well.

[Michael Mayerhoffer]

Rodney,

My wife got a chuckle reading your post over my shoulder.

My DR calls me his favorite conundrum - also been addressed as "MR. conundrum"

[Rodney Hicks]

Michael

I believe you just acquired the title MINISTER of CONUNDRUMS by default.

Rod

[John R. Heathcote]

Rod,

I believe you just acquired the title MINISTER of CONUNDRUMS by default.

Oh hockey puck putty! You beat me to it.

[StanHelton]

SHELL to PBForms

John,

Thought this might be useful in the Editor.

The call I used to PBForms is pretty simple, depending on how you feel about the SHELL statement. (I know MCM doesn't like it.):

CASE %IDC_cmdPBFORMS151
    IF CBCTLMSG = %BN_CLICKED THEN
        IF LEN(ParseReportFileList) < 1 THEN
            MSGBOX "No files to be processed.", %MB_OK OR %MB_TASKMODAL OR %MB_ICONINFORMATION, $Title
            EXIT FUNCTION
        ELSE
            MSGBOX "Files will be sent to PBForms.", %MB_OK OR %MB_TASKMODAL OR %MB_ICONINFORMATION, $Title
            tempString = "Processing .frm files"
            CONTROL SET TEXT CBHNDL, %IDC_lblStatusMessages, tempString
        END IF

        lResult = TALLY(ParseReportFileList, $Separator)
        FOR i = 1 TO lResult
            tempFileName = PARSE$(ParseReportFileList, $Separator, i)
            IF UCASE$(RIGHT$(tempFileName, 4)) = ".FRM" THEN
                tempString = "PBFORMS.EXE " & _
                                  "/C " & PBWinSubFolder & _
                                  "/" & tempFileName
                SHELL tempString
            END IF
        NEXT i
    END IF

You'll have to change CBHNDL and the %IDC_buttons to the appropriate IDs for the Editor. The directory structure built in tempString will have to be changed to the proper tree. The "/C " is necessary to get the kernel to run PBForms as a separate app.

I suppose the SHELL function could be used, but then PBForms will run in async mode. I used the SHELL statement to avoid trying to access the same files from different procedures.

I'm taking all the file I/O out to eliminate the conflict and to make code maintenance easier as you suggest.

Regarding MessageBoxes: There is an issue if we try to use MSGBOX from a DLL, but that should not matter here, since we decided to #INCLUDE the Tokenizer files. The only MSGBOX stuff the Tokenizer will use is immediate INFO, WARNING, and ERROR stuff that can be handled locally without sending a message back to the Editor. (I don't anticipate too much of this.) Anything that needs more than very minor User input will be punted back to the Editor.

Stan

[John R. Heathcote]

Stan,

The call I used to PBForms is pretty simple, depending on how you feel about the SHELL statement. (I know MCM doesn't like it.):

Thanks I'll give it a try. Shell is the means Jose Roca is using to compile source code from the SED editor.

Regarding MessageBoxes: There is an issue if we try to use MSGBOX from a DLL, but that should not matter here, since we decided to #INCLUDE the Tokenizer files.

Agreed. This was the main reason I suggested the Tokenizer returns an error message buffer to the editor as a means to handle specialized conversion error messages, and an error return message to handle general messaging requirements. All messages will be displayed by the editor, so no need to place message box functionality in a DLL.

[StanHelton]

John,

I'm busier than I expected to be right now. Just got a new gig working on POS systems. I should have more time starting Friday to tune up my end of this thing. It sounds like we may be able to begin integration testing early next week.

...
Thanks I'll give it a try. Shell is the means Jose Roca is using to compile source code from the SED editor.

Agreed. This was the main reason I suggested the Tokenizer returns an error message buffer to the editor as a means to handle specialized conversion error messages, and an error return message to handle general messaging requirements. All messages will be displayed by the editor, so no need to place message box functionality in a DLL.

I like it! As I work through the Tokenizer code this weekend I'll beef up the message spec a bit. Want to make sure there is a way to handle every thing we can reasonable anticipate.

Stan

[John R. Heathcote]

Stan,

Well believe it or not I have been working on the editor conversion between Firefly and PB SDK/DDT code. There were some tools I developed in Firefly that I would like to include in the editor so I have been converting those to run in the editor. Basically these tools allow the user to (re)format certain sections of code (to bring them up to suggested PB coding standards of course), search for unused things in the source code, flag these items, and allows the user to clean up the source code.

I think the value here is to allow the user the possibility to clean up his source code before conversion actually takes place. It made no sense to me to force the Tokenizer to convert code that could safely be removed from a procedure. Anyway I have a couple more of these tools to convert and I will send you the editor, obnoxious comments and all, this week. Sorry about the delay.

[StanHelton]

No problem. The delay monster is stalking me as well.

I like the idea of the user having an opportunity to (re)format the VB code before it hits the Tokenizer. It expects compilable VB input in order to make compilable PB output.

[John R. Heathcote]

Stan,

No problem. The delay monster is stalking me as well.

I like the idea of the user having an opportunity to (re)format the VB code before it hits the Tokenizer. It expects compilable VB input in order to make compilable PB output.

We probably ought to put our collective heads together to come up with the definitive set of tools so we don't overlap efforts.