SourceCode Only

[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 ?

[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.

[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.

[Wayne Suite]

Confusion - less

Thanks that helps.

[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.

[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 ?

[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]

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.

[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.

[StanHelton]

...
Update---

I am piecing together what bits and parts I found, soon as I can, I will donate a complete working concept model ? The missing parts I am putting in minimum code to get the point across.

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.

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. ...

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

[Michael Mayerhoffer]

Murphy is the master of multi tasking - he is visiting me too on several levels.

Update---

I am piecing together what bits and parts I found, soon as I can, I will donate a complete working concept model ? The missing parts I am putting in minimum code to get the point across.

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.

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.

Makeddt code was part of the VB to PB code converter. :crying2:


Back to business here, soon as that diamond in the rough gets packed together, I can provide more hot air service ..

[John R. Heathcote]

Stan,

I'll make this my top priority for the rest of the day. I agree with all the points you make.

Thanks. I guess we are on a roll.

You don't think there might be TWO of them?

Or more. Murphy seems to get around a lot.

I've got a lot of things going on right now: this big business trip, a few unruly clients, and some impatient creditors.

I understand, sounds like we have the same creditors.

Please forgive if I forget somethings from moment to moment.

I have to make the same claim, but in my case, my forgetfulness is due to the fact I whacked my head.

I'm going to give my problems Murphy created one more shot at fixing them, but in any case, I will send you the editor as it stands now. It should be well enough to let you know where I'm going with it.

[StanHelton]

...
I think we really need to tie down the data passing mechanism specification so we both know what we are doing.

I'll make this my top priority for the rest of the day. I agree with all the points you make.

The editor is pretty close to a workable state, if not there already. I still plan on getting what I have to you this week. Murphy paid me a visit again last night. I thought he was working with you.

You don't think there might be TWO of them?

I've got a lot of things going on right now: this big business trip, a few unruly clients, and some impatient creditors. Please forgive if I forget somethings from moment to moment.

Stan

[John R. Heathcote]

Stan,

I think you said you're writing the editor in PB (with some FireFly?).

No. The editor has been rewritten so that it is a pure PB SDK/DDT app, no Firefly involved, however, since it is a MDI app I had to use mostly SDK rather than DDT. I thought no third party GUI/RAD tools were to be used. Wasn't this the goal we set for ourselves?

In that case, why don't I just make the Tokenizer files #INCLUDEs for the editor? Everything in one place and normal procedure calls to access the various parts.

We can do that too. It should be easy as I've tried to keep the editor functionality separate from the Tokenizer.

With this method, program flow doesn't change, but implementation gets a whole lot easier.

Agreed.

For whole file conversion the Tokenizer does a synchronous SHELL to the parser which separates everything out, builds the VB Terms array, and saves it as a file with ".parsrpt" extension. Multiple files can be processed in a single SHELL.

I think we will have to let the user decide which conversion method is the better one to employ, to let the editor always feed the Tokenizer what it needs, or let the user pass the VB file directly to the Tokenizer and then view the results. Either method is doable.

The conversion method used would also be dependent on the complexity of the conversion requirement itself. I think for large projects the user may want to keep tabs on the conversion as it progresses, so the editor feeding the Tokenizer would be used. Perhaps on smaller conversions the user might want to let the Tokenizer do a batch convert then view the results. I can see instances where both conversion scenarios would be applicable.

There's a DragAndDrop listbox in the converter for processing multiple files as a batch. Might be able to use that for the WholeProject option. Right now it's pure DDT. We'll have to see if it's compatible with the editor.

I don't foresee any immediate problems. The trick is to keep both processes separate from each other and define the data passing mechanism for the editor and Tokenizer. In this way the data passing mechanism is the only direct communication the editor and Tokenizer have with the other process. Limiting communication with both processes allows for updates to occur to the editor and Tokenizer pretty much independent of the each other. Although it does not totally eliminate recoding it does minimize it to a great degree.

As a merged program the editor will have access to the GLOBAL Concordance array. Text can be placed/pulled/edited directly from that if we want, or we could, probably should, use a string buffer and let the Tokenizer do the direct modification to the Concordance.

Doable. In this case, I tend to think we should let the Tokenizer determine how it wants the data, how much data to send, and what is more convenient to do from a conversion processing stand point. The Scintilla edit control permits access of the text in a variety of ways, so the flexibility is there if we decide to use it (I just have to figure out how it works). If I need to pass an array of VB source code, or a string buffer to the Tokenizer, both can be done easily. I just need to know the specific data formats so I can create them correctly on the editor side.

One thing I don't want to do is to allow the Tokenizer to directly alter the text in the edit control. I have many reasons for this, but primarily it will be extremely difficult to keep track of the current line/position in the editor. In this case we could trash the resulting output file in the edit control by not keeping meticulous track of the text cursor. I am of the opinion that if it is a matter of text display let the edit control handle that chore, if it is a conversion let the Tokenizer handle that.

Probably should define the conditions for the editor to REDIM the Concordance: Tokenizer fiddles with it alot.

Agreed. I think we really need to tie down the data passing mechanism specification so we both know what we are doing.

BTW, if you have the editor code in a state I could work with, we could compare notes once we've each run our own tests on the merger.

The editor is pretty close to a workable state, if not there already. I still plan on getting what I have to you this week. Murphy paid me a visit again last night. I thought he was working with you.

[StanHelton]

John and Mike,

...
the loading of files in this manner will suffice.

I had a dream last night. Mike has tickled my brain into coming up with a better method that should have been obvious.

I think you said you're writing the editor in PB (with some FireFly?). In that case, why don't I just make the Tokenizer files #INCLUDEs for the editor? Everything in one place and normal procedure calls to access the various parts. Since I've got the event CLASS and the COM CLASS mostly built, we could use internal objects to handle the messaging (no GUIDs required) and the GLOBALs would be available to both editor and converter because they are one and the same. With this method, program flow doesn't change, but implementation gets a whole lot easier.

For whole file conversion the Tokenizer does a synchronous SHELL to the parser which separates everything out, builds the VB Terms array, and saves it as a file with ".parsrpt" extension. Multiple files can be processed in a single SHELL. There's a DragAndDrop listbox in the converter for processing multiple files as a batch. Might be able to use that for the WholeProject option. Right now it's pure DDT. We'll have to see if it's compatible with the editor.

...
Changes made to VB code will be reflected in the editor so the user will have a visual feedback of the process as it occurs.

As a merged program the editor will have access to the GLOBAL Concordance array. Text can be placed/pulled/edited directly from that if we want, or we could, probably should, use a string buffer and let the Tokenizer do the direct modification to the Concordance.

Probably should define the conditions for the editor to REDIM the Concordance: Tokenizer fiddles with it alot. Or we could just use the internal objects. (thinking as I type.... almost always a mistake. ) Oops, that's a detail, isn't it.

Before we get too wrapped up in details I think we need to merge the Tokenizer and the editor together to see what the ramifications are before we proceed further.

Exactly! ... ok, so I'm coming late to this particular party, I'm here now.

Give me a few hours to modify the Tokenizer files appropriately and I'll post them here in a zip. I need to chop up the parser a little bit also to get the appropriate functions into the Tokenizer proper (instead of using SHELL).

Stan

BTW, if you have the editor code in a state I could work with, we could compare notes once we've each run our own tests on the merger. sjh

[Michael Mayerhoffer]

Stan

that makes things much clearer now.

John moving that to PB or leaving it as is ?

Leads me to more questions and thoughts, I will get back to you tomorrow or so. Need to rest a bit for now.


------ John I agree, get back to you too... forgot to post this and seen you posted while this was sitting in no where land..did not want to think I ignored your post.


Mike

[John R. Heathcote]

Stan and Michael,

...and a half with Mr. Murphy looking over my shoulder.

Murphy seems to be everywhere, he seems to visit me on a regular basis.

I'm not sure how John is implementing the user options, ...

Right now the only user options I've implemented is to load and save specified file(s) from the OpenFile and SaveFile dialogs. The user clicks on a loaded file in the editor to make it the current file (assuming more than one file is loaded at a time). From there the user would select a conversion level and begin the conversion process. There are tools to assist the user in cleaning up the converted code.

Obviously one user item I would like to add is to handle conversion on a project level, but I think that may have to wait until a later version as I'm unsure exactly how we want to set up this feature. For now, I think the loading of files in this manner will suffice.

General flow:
1 - open files in editor
2 - ==> pass selected VB code to tokenizer
3 - ==> pass PB code back to editor
4 - ==> user has option to accept, decline, manual edit

This is the way I envision it too.

5 - ==> process repeats until user is satisfied or quits in frustration

Or far too many OBNOXIOUS COMMENTS.

Changes made to VB code will be reflected in the editor so the user will have a visual feedback of the process as it occurs.

Before we get too wrapped up in details I think we need to merge the Tokenizer and the editor together to see what the ramifications are before we proceed further.

[StanHelton]

Stan
I believe I see your concept or what you want to accomplish. I see no reason for using or not using com, up to you.

Thanks for the feedback Mike. The interaction John and I have been planning is for the editing to take place in an application he is writing based on Scintilla. My idea was to run the converter separately, but now I'm not so sure after working with the COM interface for the last day and a half with Mr. Murphy looking over my shoulder.

After seeing the server sample, I realize I am missing some of the picture here.

I am trying to fast track the overall picture. I am asking more for a general flow of conversion not real detailed stuff. ...

General flow:
1 - open files in editor
2 - ==> pass selected VB code to tokenizer
3 - ==> pass PB code back to editor
4 - ==> user has option to accept, decline, manual edit
5 - ==> process repeats until user is satisfied or quits in frustration

I'm not sure how John is implementing the user options, but here's a list of what relates directly to the converter:

Line-by-line
Procedure-by-procedure
File-by-file
Whole Project

Given your initial comments and my 2-day headache with COM, I'm beginning to think we would be better off with one huge executable that uses internal objects and events. John is subsuming most (if not all) of the user editing functions into his app. I've stripped most of the dialogs out of the converter. That would greatly simplify the need to pass messages; we could just set flags and procedure return values.

PS I think that the self registering part would be a viscous loop. You would have to load the DLL and it would then register and re-entry would cause it to re register... ... ... ...

You are absolutely right! I had to take that out on the first test run after I posted that code. Beginning to think I forgot the KISS principle when I thought this up .... again.


Stan

[Michael Mayerhoffer]

I'm impressed. I've got only about 20 gig that was worth saving.


What did you think of the admittedly raw and incomplete server I posted? I would be very interested in your comments if you could take a moment to look at it.

Be safe and be well on your trek.

Stan

Stan
I believe I see your concept or what you want to accomplish. I see no reason for using or not using com, up to you.

After seeing the server sample, I realize I am missing some of the picture here.

I am trying to fast track the overall picture. I am asking more for a general flow of conversion not real detailed stuff.


general flow such as ---

open files in a editor - process - complete and mark troubling code..

or open files - process - stop and advise correct what ever - Please play again to complete.



This would really help me catch up jumping in the middle of things.

Thanks

Mike

PS I think that the self registering part would be a viscous loop. You would have to load the DLL and it would then register and re-entry would cause it to re register... ... ... ...

[John R. Heathcote]

Stan,

Can hardly wait to see what obnoxiousness John wants out of it to make the editor work

Well there really isn't any obnoxiousness (is that a word, if not, it is now) needed for the editor to work. I've tried to keep the interface between it and the Tokenizer as separate and as simple as I can get it. Right now, the editor can pass as few or as many lines as the Tokenizer needs to do its thing. With the Tokenizer passing back the converted line(s) along with a status of success or failure, I'm pretty much set. All I really need at this point is the Tokenizer calling sequences, property sets, etc. I'm sure there will be many changes necessary in the editor to successfully merge the capabilities of the Tokenizer, but that goes with the territory, so no biggie.

What did you think of the admittedly raw and incomplete server I posted?

Like Rod, I guess I'm having a hard time seeing the advantage of a server based process. Are you planning to give the user the capability of running the Tokenizer as a separate process without the editor? I'm ok with that, but based on the limited VB to PB conversions I've done so far it is much easier with the editor than without. On a large VB project I cannot imagine performing conversions without the editor. If there is one thing I've learned from my conversions is visual feedback is very important as the conversion process is iterative in nature.

BTW, the editor recoding effort from Firefly to SDK is proceeding well for a change. Hopefully I will be able to send it to you sometime this week as I promised, assuming Murphy doesn't show up again. He is the true MINISTER of OBNOXIA, I learned everything I know from him.

I'm also working on converting some of the Firefly utilities I've developed as they will assist the user in code formating, maintenance, manual coding etc. I have most of these recoded, but need to test them. A tidbit of information you might be interested in is that I'm using the source code utilities for the editor to help write and clean up the editor.