Quick queston Stan

[StanHelton]

...
IMO we should keep file management in the editor just to keep things consistent. We would always run the risk of overlooking or missing ...

Agreed on all points.

I think I just added another item on my list of things to do.

Funny how that keeps happening to me too, almost every time I check this forum.

Posted some code in the SourceCode thread that might be useful for you.

Stan

[John R. Heathcote]

Stan,

John's Editor has these features, if I understand it correctly.

Not yet, it's on my list of things to do. Right now I am more concerned creating a stable editor platform with SDK and DDT in the rewrite from Firefly.

John,
Would like your thoughts on keeping this function in the Tokenizer or moving it to the Editor?

IMO we should keep file management in the editor just to keep things consistent. We would always run the risk of overlooking or missing something between the editor and Tokenizer if the file maintenance capabilities were overlapped. If file maintenance is handled by the editor then we would always know where to look for problems.

I think I just added another item on my list of things to do.

[StanHelton]

Attached is a simple vb program, I put it together today because the more I thought about what I had attached in the other topic the more I thought that initially you may need something simpler for development and move from there. ...

This is good... and I see you have stimulated a good discussion on the GUI issues.

...
With all that said and going with the thought when the END USER converts a VB PROJECT to PB WIN the process which I see happening would be:

USER - 1. BACKUP THE VB PROJECT IN ANOTHER FOLDER

We decided on a directory structure last week. See

http://www.powerbasic.com/support/pbforums/showthread.php?t=37766&highlight=PBWinFiles&page=2

Posts #17 & #18

USER - 2. Using PBFORMS 1.51 import the vbform from the VB PROJECT

CONVERTER - 3. Convert the .frm code in the form to PB WIN code
CONVERTER - 4. Save the created PB WIN code

File I/O will be handled by the Editor. John will have the details on how this works. I'm catching and changing details in the Tokenizer so that it doesn't conflict with the Editor on file I/O.

CONVERTER - 5. Call the PBWIN compiler to compile the converted code
CONVERTER - 6. Create an PB2VBError.txt file with Error / Status Messages from the attempted compile.
CONVERTER - 7. Ask the user if he wants to open the Editor to modify the coverted code or Just Exit after the CONVERTER Renamse the Error.txt to Reflect the VBPROJECT Name like so: SIMCONVERTPBERROR.TXT. At this point the user could then modify the source code and then some option be available in the converter so the modified code could compile attempted again with a newer Error.txt file created as required.

John's Editor has these features, if I understand it correctly.

...
What I am seeing from the user aspect is that the user should only have to manually use PBFORMS1.51 to import the form after he backs up his project then point to the main form file in the project to initiate the conversion. Then when its done sucessfully it exits.

There's a synchronous SHELL in the Tokenizer to do this.

John,
Would like your thoughts on keeping this function in the Tokenizer or moving it to the Editor?

Please correct my thinking if I am totally out to lunch on the way it works

You're right in line with what we're trying to do.

...
PBForms establishes some fundamentals, ie: CALLBACK FUNCTION, program layout, and because PBForms takes the vb.frm files gives the new user a quick lesson on programming in PB. ...

PBForms provides an excellent skeleton for the GUIs. Functionality is a bit more problematic. See Mike's and Brian's comments for more on this.



Gotta run. Will check back later this afternoon.

Stan

[Michael Mayerhoffer]

I looked

Is is a standard button can not set color as I mentioned there is 2 ways of doing this. Using an image button or a custom button.

Now before you bust my chops VB does not use real controls.

So that's why you can change colors on the fly. VB really don't use real anything per say.

So if it is something you want to do now - look at CONTROL ADD IMGBUTTONX statement.

[Michael Mayerhoffer]

The

Although neither of them included the Icon on the form nor did either of them provide the original colors of the form or the command buttons.

Just an observation and quick test.

Just for info if its of any use to anyone.

The user using the converter will have to supply the original embedded resources. VB does not reference the embedded files pieces and parts they use, not even sure we could use the pieces and parts. The bigger problem is they don't reference them a way one could decipher which one is which.

Bottom line. just as you selected them in VB you will have to in PB. Certainly beats converting 10,000 lines of code and 20 forms by hand.

The color issue, there will be color. I would have to look at your sample(and will) to see why it was not there. Normally Push Buttons do not support alternate color by Winapi32 standards. Default Windows color scheme only.

PBwinspy - enumerates through the running windows and retrieves class types and sizes and with out going through detail they usually look better it really doesn't get the full picture.

[John R. Heathcote]

Wayne,

Although neither of them included the Icon on the form nor did either of them provide the original colors of the form or the command buttons.

Just an observation and quick test.

I was afraid of this.

How difficult would it be to manually add the missing items in the converted PB code? I know this isn't the point of conversion, but we may have to live with this "feature" you've discovered, at least for Version 1 until we get a handle on the whys and wherefors of generating our own form converter.

Just for info if its of any use to anyone.

"Undocumented features" are always good to know about.

[Wayne Suite]

Followup

The simple vb project I posted earlier today just for the fun of it I Imported the form using PBForms 1.51 then I used PBWINSPY1.7 with the DDT option selected then I used PBWINSPY1.7 with the SDK option selected.

The results Comparing just the 2 PBFORMS1.51 and PBWINSPY1.7 with the DDT option resulted in guess what. PBWINSPY1.7 converted the form and included the command buttons on the form although only 1 of them did anything and exited the program while PBFORMS1.51 when it converted the form not only did not INCLUDE ANY command buttons showing (although the code for them was included) but the opaque form was not transparent and the desktop background was included in the form while in PBWINSPY1.7 the form was opaque.

I did not alter ANY code just compiled it and ran the compiled .exe and compared it with the original VB form. So not being a coding genuis in PB from an observer observing the 2 created exe's from the same form I would say PBWINSPY1.7 done a better job in replicating the form.

Although neither of them included the Icon on the form nor did either of them provide the original colors of the form or the command buttons.

Just an observation and quick test.

Just for info if its of any use to anyone.

[John R. Heathcote]

Wayne,

The one thing I have discovered in converting my own VB files is that each project/conversion will probably require different conversion strategies. My VB surface modeling program, for example, has most of its functionality confined to the modules that produce the triangulated mesh as opposed to the dialog boxes that invoke the program, so it makes more sense to spend my efforts converting the processing modules. Another VB project may require concentration on converting VB dialog boxes. This issue should be left up to the user.

The editor portion of the converter project is supplied to give the user some visual feedback of the conversion process as it happens and to provide some simple code editing capabilities for the user. The Tokenizer is the process that actually converts the VB source code to PB. Stan can give you all much more info on that process than I can.

As Rod mentioned the reason we are using PBForms is its ability to convert VB code so we don't have to reinvent the wheel, but more importantly, we are getting ready to put the converter pieces together and there are plenty of unknowns in this process. So if PBForms can fill an important conversion process, even temporarily, it is a plus and one less thing we have to do.

Brian,

Would anyone mind if I work on the Form converter? Does this sound like the right solution or is PBForms the way to go?

I would say, go for it. Michael Mayerhoffer has some code to do something similar, perhaps you two should compare notes on the issue.

Rod,

Good summary, and spot on.

[Rodney Hicks]

We had decided to use PBForms to handle the .frm files simply because it does such a good job at converting those files. Sorta like why re-invent the wheel.
The trick is to then take the converted (output) and meld it with the remaining VB files.
PBForms establishes some fundamentals, ie: CALLBACK FUNCTION, program layout, and because PBForms takes the vb.frm files gives the new user a quick lesson on programming in PB.
We thought we'd take advantage of that.
This decision was made prior to PBWin 9.0 being in existence when there were only three of us working on the project trying to get our heads around all aspects inside of some sort of time line.

A separate form converter could be made for users that want to code SDK style programs. This I think we had latered to a later version of the converter. With more hands at the task, more can get done.

What I'm saying here is that this may be the time to consider additional features if they can be implemented smoothly with our existing progress.

We did not expect the initial version of the converter to be fully comprehensive, that is, we knew that there would be some areas lacking. One of the areas was that we weren't going to tackle anything but text based VB files.

I fully expect Stan and John can be more specific on these issues, this is an 'information only' post describing whatnots wherefores as we've been inching along.

[Brian Chirgwin]

I'll try to answer.

The zip contains 4 source files and the .exe. The .frm file of course contains the form info and the form coding. The .vbp contains information about the project such as name etc. The .vbw contains the position of the main form it looks like. This leaves the .frx file which if opened in a hex editor contains 778 bytes which I am assuming similiar to M$ Basic would contain the tokens possibly for the program coding.


Wayne

.frm - Frm and Form code
.frx - Control addons and other data, bitmaps, etc... Forms only have this for extra data that is not stored in the .frm file.
.vbw - only require for the VB IDE. Contains what files are open and there locations. Can be ignored.
.vbp - Contains project info, name, controls.

In addition there are
.bas - code only module (no form)
.cls - class/object
.ctl - user control
.vbg - a file that lists a group of projects that are related and opened together in the VB IDE.

USER - 1. BACKUP THE VB PROJECT IN ANOTHER FOLDER
USER - 2. Using PBFORMS 1.51 import the vbform from the VB PROJECT

1. A copy of the VB project should be made to the PB output directory. This could be optional. In other words, a dialog asks for the project to convert and a output directory. The following sub directories (or something similar) are created

Root
- VBsource
- PBsource

2. Although it has been stated that PBForms can be used I have thought all along to write a converter for the forms. PB Form is ok to start. My reasons for a form converter are as follows:

• PBForms doesn't know about third party/ocx controls (I don't think). If I remember correctly unknown controls come in as pictures (image?).
  
• It may be necessary to replacement some controls with alternatives. For example, Instead of using the default textbox, a PBTextbox could be used that provides some under the hood VB functionality for the conversion.
  
  The CommonDialog Control. This control is not necessary and can be removed, but the name of the control is required to change the VB code to use CommonDialog without using the control.
  
  In VB an option button group works differently than in PB. This will require generating different code (PBForms might actually do this, not sure).
  
• We may have several control alternatives. For example, MSGrid to EGrid32, SIGrid or one of the many other controls.
  
• Controls have properties that may need to be changed from what they are in VB. I am not sure what PBForms does, but why require a user to change the PBForms code (or have to tinker with it programmatically) when the VB Source is there.
  
• I believe we will find we are reading and interpreting the form control code/layout and code anyway. i.e. Control names, types, and maybe some other properties. For example, code that is behind a button click (cmdCommand_Click)? Having the converter add a few dialog create/add control lines isn't that much more difficult (I don't think. Haven't done this yet, so I am not sure).
  
  

The above is still somewhat theory, and we may not require all steps, but I think there is functionality that is required.

In summary, I see a step (one in a wizard) where the used controls are analyzed and the user has an option on some to select what control they wish to use in the PB Project.

I know haven't been involved much in the project to date. I am finishing up some work and plan to start put some time into this in the next two weeks.

Would anyone mind if I work on the Form converter? Does this sound like the right solution or is PBForms the way to go?

[Wayne Suite]

Attached is a simple vb program, I put it together today because the more I thought about what I had attached in the other topic the more I thought that initially you may need something simpler for development and move from there. Baby steps instead of Giant ones. Anyway here it is both the .exe and the source code in the .zip.

Using this source code in the .zip I have a few questions to get me up to speed on the BIG PICTURE.

The zip contains 4 source files and the .exe. The .frm file of course contains the form info and the form coding. The .vbp contains information about the project such as name etc. The .vbw contains the position of the main form it looks like. This leaves the .frx file which if opened in a hex editor contains 778 bytes which I am assuming similiar to M$ Basic would contain the tokens possibly for the program coding.

With all that said and going with the thought when the END USER converts a VB PROJECT to PB WIN the process which I see happening would be:

USER - 1. BACKUP THE VB PROJECT IN ANOTHER FOLDER
USER - 2. Using PBFORMS 1.51 import the vbform from the VB PROJECT

CONVERTER - 3. Convert the .frm code in the form to PB WIN code
CONVERTER - 4. Save the created PB WIN code
CONVERTER - 5. Call the PBWIN compiler to compile the converted code
CONVERTER - 6. Create an PB2VBError.txt file with Error / Status Messages from the attempted compile.
CONVERTER - 7. Ask the user if he wants to open the Editor to modify the coverted code or Just Exit after the CONVERTER Renamse the Error.txt to Reflect the VBPROJECT Name like so: SIMCONVERTPBERROR.TXT.

At this point the user could then modify the source code and then some option be available in the converter so the modified code could compile attempted again with a newer Error.txt file created as required.

Of course if the project is converted sucessfully(desired!) then a completion message generated and the CONVERTER program ends.

What I am seeing from the user aspect is that the user should only have to manually use PBFORMS1.51 to import the form after he backs up his project then point to the main form file in the project to initiate the conversion. Then when its done sucessfully it exits.

Please correct my thinking if I am totally out to lunch on the way it works

Thanks, I also included the hex dumps of .frx in .pdf format

In the .zip included you can ignore the open folder icon somehow I included it in the .zip and could not remove it.

Wayne