VB Form Conversion

[John R. Heathcote]

Stan,

While I was trying to get a better handle on managing VB files at the project level I kinda got sidetracked on the VB .FRM files. I noticed the layout and definition of the event procedures are pretty well compartmentalized and that lead me to wonder if we could apply the same level of compartmentalization to the converter.

My idea was this; instead of having one callback function to handle the entire form, establish an individual callback for each control. This way we could create a template file for individual controls that could contain standard windows messages that we could plug in to the generated PB source code.

For example, the combobox control callback template might look like this:

CALLBACK FUNCTION <cb-ComboBoxName> () as LONG

  SELECT CASE cb.msg
    CASE %WM_COMMAND
      SELECT CASE CB.CTL
        'Find the individual button controls from the Visual BASIC .FRM
        'file.  This part of the SELECT CASE structure is built on-the-fly.
          CASE <comboboxid>
            'Add the Command Button event messages.
            'The individual control event messages can be inserted from a
            'template file.
            SELECT CASE CB.CTLMSG
              CASE %CBN_CLOSEUP
                ''##BEGIN _CLICK() Event
                ''##END _CLICK() Event

              CASE %CBN_EDITCHANGE
                ''##BEGIN _CHANGE() Event
                ''##END _CHANGE() Event

              CASE %CBN_SETFOCUS
                ''##BEGIN _GOTFOCUS() Event
                ''##END _GOTFOCUS() Event

              CASE %CBN_KILLFOCUS
                ''##BEGIN _LOSTFOCUS() Event
                ''##END _LOSTFOCUS() Event

              CASE %CBN_SELCHANGE
                ''##BEGIN _CLICK() Event
                ''##END _CLICK() Event

              CASE %CBN_DBLCLK	'Occurs only for the CBS_SIMPLE style.
                ''##BEGIN _DBLCLK() Event
                ''##END _DBLCLK() Event

              CASE ELSE

            END SELECT

          CASE ELSE

        END SELECT

      CASE %WM_CLOSE

      CASE %WM_DESTROY

      CASE ELSE

  END SELECT

END FUNCTION

We could then insert the VB event code between the ''##BEGIN and ''##END comments pretty much as is without having to figure out the context of the VB code and then attempting to insert it into a single callback function at the appropriate place and hope we get it right. This way the converted Vb code is associated with a Windows %WM_COMMAND or %WM_NOTIFY message and still gives the user a familiar point of departure via the VB event code procedure name. Frankly, I wish PBForms did something like this to help the users identify Windows messages and how they relate to the real world.

Anyway, just a thought.

[Rodney Hicks]

Frankly, I wish PBForms did something like this to help the users identify Windows messages and how they relate to the real world.

Strangely, it is because PBForms handles the controls the way it does that helped me get my head around a lot of issues. But then, I never got into VB as a programmer and don't know what I'm missing, which I ain't missing.

The fashion that you're proposing can be made to work, however, we may lose some of the advantage of the DDT style coding, because it seems that what we'd end up with is more SDK style using DDT. This is enlightening, for there is nothing wrong with either, just a matter of personal preference.

Just a matter of what gets the job done. Fine tuning can be latered.

Question, can you imagine trying to write a converter for PB to VB handling all the different PB accepted coding practices?
I think we got the easy job.

[John R. Heathcote]

Rod,

Strangely, it is because PBForms handles the controls the way it does that helped me get my head around a lot of issues.

Well I'm glad PBForms helped you, however, it didn't do much for me. As a new PB user I found the rather sketchy and sparse source code PBForms output caused me more problems than it solved. I wanted to know which Windows message corresponded to a ListView header column click, for example, but found PBForms does not output this information (although it should be available). Again as a new PB user I knew what I wanted to do, but PBForms did not show me how to do it. IMHO PBForms does a good job of forms design, but it is somewhat weak on the underlying functionality (Windows messages) part. From what I gather from the many forum questions posted by users is that the concept of Windows messages is the number one stumbling block to many new PB users, they still confuse me to no end for sure.

The fashion that you're proposing can be made to work, however, we may lose some of the advantage of the DDT style coding, ...

This is DDT style coding. Many of the DDT examples in the \Samples directory follow this style of coding too. I would guess multiple callbacks is not a widely used DDT programming technique, but it is available to us nevertheless.

...because it seems that what we'd end up with is more SDK style using DDT. This is enlightening, for there is nothing wrong with either, just a matter of personal preference.

Agreed. But I also have observed that simplicity plays a part too. As I have mentioned before large callback functions are difficult to code and maintain, even the callback routine in the editor is getting quite large and is starting to become difficult to deal with effectively.

So what to do? Do I keep the single callback or bust it up into several smaller callbacks? An issue we need and should consider.

Just a matter of what gets the job done. Fine tuning can be latered.

Yes and no. Yes, if the added tweakages do not disrupt existing functionality or software design. No, if such tweakages cause major portions of the converter source code to be rewritten, which we will probably have to do anyway for the first couple of versions. All I'm suggesting here is that a proper analysis be done on some of the aspects of converting VB to PB as I think we will save ourselves many headaches later on in the life of this project.

Just as an exercise I thought I would see how difficult it would be to create some routines to convert a VB form from one of my own VB projects. The first thing I noticed is the complexity of the problem is directly and proportionally related to the use of the single or multiple callback design.

If we used a single callback the big issue, to me, was to somehow shoehorn the VB functionality with its many controls and event code into a reliable CallBack function where the original VB application functionality would be preserved. This meant we would have to somehow consolidate VB source code and decipher it's intent for this to happen. It's been my observation that when one tries to consolidate functionality something always is left out in the mix usually causing the application to almost work as intended.

Now, I'm not saying a single callback couldn't be done, but it just seemed to me the easiest thing to do from a conversion functionality point of view, was to use multiple callbacks to preserve the VB compartmentalization of the controls and event code. Multiple callbacks require no continued parsing of VB code, no multiple passes through the VB source code to determine intent, each VB control can be reduced to functionality contained in a preprogrammed template file, and the intent of the VB application is preserved, which would be familiar to the user. The only thing that would be missing is an omission in the VB code itself and that is something we cannot foresee or correct in the conversion. The user will have to make those corrections, but then, they would have to do this anyway.

But you're correct, multiple callbacks creates more source code, but in this instance I think it is worth it.

Anyway, that was my $0.02 analysis of the problem so I put it out for public consumption (and criticism).

[Brian Chirgwin]

Does multiple callbacks really take more code?

Taking the PB 9 samples\ddt\Hello application which is written using separate callbacks. Converting it to a single call back didn't really add any more code

Original Code
Each control had its own callback i.e. Add Control CALL callback

Each control processes its own message.

Single Callback function (On Form)

Dialog Show ... Call callback

In the dialog callback you need to check %WM_COMMAND and for which control ID.

if cb.msg =  %WM_COMMAND then
 select case cb.CtlID
 case control1 
    process
 case control2 process
....

What am I missing? The code doesn't look that different. Function declares vs. an if and select statement. I am open to either choice I am just pointing out I don't see a big difference in the source code generation. A style preference perhaps.

Even if I used a single dialog callback, I would call a function (not call back) that actually performed the vb code. This would make it easier instead of having to view a huge dialog callback function.

I did a test. I'd post it, but I modified the sample and not sure if it is ok to post the PB samples.

As long as the Control Callback returns 0, the dialog call back is then called. This could allow code in both places. I could potentially see code that is provided for all controls as part of the VB2PB framework in the control callbacks and the vb code in the Dialog Callback. Control Callback is called first and if a non zero value is returned, it won't call the dialog callback (cancel vb code from running). We may find that we need some pre-processing in the conversion. Just a thought.

But you're correct, multiple callbacks creates more source code, but in this instance I think it is worth it.

[Rodney Hicks]

but it is somewhat weak on the underlying functionality (Windows messages) part.

This is true, but that is Windows programming, from a PBer point of view. PBForms just gave the form, gave you a callback function with the most used messages and left it up to you do more. Generally, PB gives you the coding tools, but it leaves the coding to you, with the sole exception of what little PBForms does.

For this reason, I say go with what makes most sense to you now. There could be lots of other ways to do this job. When the converter is released, we'll get a lot of 'You should have', 'You shouldn't have', 'Why'd you', 'Couldn't you have', about what was done, not to mention the new features users will want.

As I have mentioned before large callback functions are difficult to code and maintain, even the callback routine in the editor is getting quite large and is starting to become difficult to deal with effectively.

I'll let you in on a little secret, just don't tell anyone. My callback functions get horrendously large on me, and I'm glad their capable of it, but that is because I'm a linear thinker, I think. I like having all the controls in a window accessible in one callback, that way I don't have to go looking.(It's bad enough I have to look for them within the callback,which in some ways isn't any different.) But that is me and my cross to bear. You will be aghast to find out that I'd rather use a gosub then create a function outside the callback. It has its advantages for ME. In truth, I'm a little jealous of those that can think in modular terms. The more modular I get, the more I see of that Murphy type fella. This may be because I don't see the opportunity as others do. I'm not advocating that you program in my style.

But to me that is part of the Power of PowerBASIC. They have similarities to other languages, but seem to empower the programmer with more freedom. But that means choices and doing it myself.

I reiterate, go with what makes most sense to you. You will be more comfortable with what you're doing, the job will go easier for you, and you will have some peace of mind and be more pleased with what you accomplish. I'll try and keep Murphy busy for you.

From what I gather from the many forum questions posted by users is that the concept of Windows messages is the number one stumbling block to many new PB users, they still confuse me to no end for sure.

This stems from Windows, because they who created the monsters didn't put all the information on each message in one place, or if they did, were unclear about it. For PB to accumulate all that is required for us would be like them doing Windows' work instead of PB work, even though PB rides on Windows. It may also be a side effect of the number of different messages and notifications that might be sent because we don't always know what the operating system is doing(and I never really know what I'm doing).

[John R. Heathcote]

Brian,

Does multiple callbacks really take more code?

I think it depends on how you set up your callbacks. Your point is well taken when it is referenced against the DDT samples.

I was thinking more in terms of the generated source code from the converter using a standard control callback template file. I was attempting to create a standard individual callback for each control that contained the general events, most of them anyway, that are usually found in VB source code. To do that it was necessary to expand the Select/End Select Case statements to include Windows messages that may never get referenced in the equivalent VB event. If we find that we need to respond to a Windows message that is missing from the template file it would be a simple matter to add that functionality.

Using multiple callbacks allows us to plug in the combobox template, for example, if it is referenced in the VB source code and utilize the VB event code rather than hard code this functionality into the converter. I think this modular approach has some advantages, but I would like to hear other members comment on this idea too.

Rod,

This is true, but that is Windows programming, from a PBer point of view. PBForms just gave the form, gave you a callback function with the most used messages and left it up to you do more. Generally, PB gives you the coding tools, but it leaves the coding to you, with the sole exception of what little PBForms does. (Italics are mine).

This is my point. PBForms could (and should) do more in the area of code generation, even if this was a user defined option that could be turned ON/OFF by the user. PBForms gives you all this wonderful capability to graphically create your dialog boxes with almost no code provided to actually make it work. Now I realize PBForms can not be all things to all people, but IMHO what code PBForms does provide is just short of rediculous. IMO PowerBASIC is missing a golden opportunity from a business perspective to help educate their users in the complexity of Windows messages, thus making their software easier to use, and at the same time help eliminate the frustration of knowing which Windows message accomplishes a specific goal.

My callback functions get horrendously large on me, and I'm glad their capable of it, but that is because I'm a linear thinker, I think. I like having all the controls in a window accessible in one callback, that way I don't have to go looking.(It's bad enough I have to look for them within the callback,which in some ways isn't any different.)

I know exactly what you mean. This is one reason I've adopted a form/control/callback naming convention that helps me organize things so they are easy to find. For example, a dialog callback may be named as "proj_DLG_VBPRJ_PROJ_Show". A lot of underscores but it works for me. A control id may be defined as "CTL_VBPRJ_PROJ_lv01". The common "VBPRJ_PROJ" theme lets me know in the code finder that the dialog and controls belong together.

But to me that is part of the Power of PowerBASIC. They have similarities to other languages, but seem to empower the programmer with more freedom. But that means choices and doing it myself.

In most cases I do enjoy the freedom after I know what Windows messages I need to respond to and how to call the same. Nothing is more frustrating to me than to be in development mode then I have to switch hats to a research mode (particularly when the research mode takes days) to look up how to do something usually simple, then switch back to development mode again and continue with what I'm doing. Not a productive use of my time. I just think PBForms could provide more structure to help the user as it does not link what you want to do with how to do it scenario, which is the primary goal and purpose of any RAD tool. Which should also be a goal of our converter as well. The dialog boxes designed in VB have to work in PB after the conversion.

This stems from Windows, because they who created the monsters didn't put all the information on each message in one place, or if they did, were unclear about it. For PB to accumulate all that is required for us would be like them doing Windows' work instead of PB work, even though PB rides on Windows.

I guess this is one area we will have to agree to disagree. I am of the opinion PBForms could generate more source than it does with little or no effect on the user. Take another look at the combobox template file and then tell me that the inclusion of this source code, or something like it by PBForms, would seriously jeopardize the function of any application.

I guess the point to all of this is we need to have a way to convert VB dialog boxes/functionality into its PB equivalent. We should think very seriously about how we intend to do this.

[Rodney Hicks]

I guess this is one area we will have to agree to disagree.

I don't know that disagreeing is the issue here, for if I was coming to PB from VB I think I'd be saying exactly what you're saying. Very early on I tried VB but I found I couldn't do some of the things I wanted the way I wanted and so I dropped it like a hot potato.
I understand what you're saying about code generation, however, PBForms is a forms generator that generates some code as a starting point for the coder. It is not meant to be a code generator, and ergo, it does its job.
This is why some of the third party tools exist, for those that want code generated with their forms. I haven't done a study on this but I believe most that want code generated are accustomed to Visual whatever languages.
The difference is somewhat subtle, but that's PB's way of letting you code your projects in the manner you want, as opposed to the manner they dictate. For me, it allows greater creativity, but for others.. well, I just can't speak for them.

Your idea of a "Generate Message handling code" type toggle or some such, might be a future consideration, but I sometimes think that PB doesn't want to intrude on third party territory. It is also pretty hard for them to be all things for all people.

[John R. Heathcote]

Rod,

I don't know that disagreeing is the issue here, for if I was coming to PB from VB I think I'd be saying exactly what you're saying.

I appreciate that.

I've used VB from version 1.0 to 6.0 and I've seen it grow (pun intended) to the slow, horrible bloatware, conglomeration it is today. VB.NET! Why? That's why I chose PowerBASIC. I've also used Firefly, EZGUI, and Phoenix to generate applications from the structured approach provided by these third party developers and not once have I ever thought these RAD tools limited or otherwise stifled my creativity in any way. Using these RAD tools allowed me to increase my productivity many times over what PBForms offered. I guess maybe it's the way I code, but PBForms for me is actually a hinderance to my overall productivity.

Your idea of a "Generate Message handling code" type toggle or some such, might be a future consideration, but I sometimes think that PB doesn't want to intrude on third party territory. It is also pretty hard for them to be all things for all people.

In this case I don't think PB would be intruding on third party territory, but even if they do the competition between PB and the third party RAD tool developers will only serve to improve their respective products, and the end users will benefit because of it.

If PBForms gave me the choice of customizing callback code generation to my liking they could be more things to more people, which ain't necessarily a bad thing. Again, IMO PB could do more in the source code generation area, but for some reason choose not to do anything about it from a business point of view. Which is strange as PB does have the technical expertise at their disposal to accomplish such a goal.

But I think we're getting off-topic here, although it was nice to blow off a little steam for a bit. My main reason for this thread was to put forth my analysis of generating the equivalent PB form, plus event code, from the original VB project. I still think it is possible to generate this type of callback source code and may not be quite the headache we all envisioned, however, the success or failure of this particular endeavour will largely depend on the analysis that is performed by the group. I'm saying that PBForms does not quite fill the coding gap I think we need to provide our users.

I would really like to hear the thoughts of the other group members on this issue, particularly since most of you have far more experience converting VB forms to PB than I do.

[Rodney Hicks]

I've also used Firefly, EZGUI, and Phoenix

Do any of these provide a conversion from VB option?
I agree, it would be nice to hear from others, but until we do, I would go with what your most comfortable with.

[John R. Heathcote]

Rod,

Do any of these provide a conversion from VB option?

No they don't. Firefly is probably the closest to VB of any of the RAD tools. We, of the VB conversion project, are charting new ground here.

I agree, it would be nice to hear from others, but until we do, I would go with what your most comfortable with.

Other than some exploratory coding efforts and my analysis of the forms conversion problems I don't have anything to put into the editor. I was under the impression Michael and Brian were seriously investigating converting VB forms to PB, so I did not want to intrude on and/or duplicate their efforts.

[Rodney Hicks]

so I did not want to intrude on and/or duplicate their efforts.

Yes, I understand, reinventing the wheel is so.. so... redundant. Sounds like a task for Murphy to keep him out of our hair.

Are we going to need a Minister of OXYMORONS?

[John R. Heathcote]

Rod,

Are we going to need a Minister of OXYMORONS?

Did you just volunteer?

[StanHelton]

I'm Back

Hello Rod, John, Brian (in no particular order)

I've been building networks in Atlanta this week ... I'm tempted to quote Ron White, "You can't fix stupid." Anyway that's another story that THANKFULLY does not apply here! There were some good moments, too. Very glad to be back!

Interesting discussion. I'd like to cast my vote for CONTROL CALLBACKS even though it doesn't really suit my style. I like most things in one place like Rod, but like Brian, I try to use FUNCTION calls for the complex stuff that would just be messy inside a PBForms type of skeleton.

Although the CONTROL CALLBACK method doesn't fit my natural coding style, I think it would make more sense to a VBer just coming over to PB. They'll be used to seeing separate functions in the VB editor for the controls. If that's as far as they want to go with it, fine. But once VBers get a feel for the flexibility of PB, I think we'll find at least as many different styles as we have here in the group.

From my perspective, it's one thing to take some VB code and convert it, and quite another to provide a tool that will help VB refugees get up to speed in PB. I tend to trust your insights on this kind of thing, John. You're closer to it than I am.

Anyway, there's my $700,000,000,000.00 .... (<== political joke )

Stan

[Rodney Hicks]

I noticed the layout and definition of the event procedures are pretty well compartmentalized and that lead me to wonder if we could apply the same level of compartmentalization to the converter.

We could then insert the VB event code between the ''##BEGIN and ''##END comments pretty much as is without having to figure out the context of the VB code and then attempting to insert it into a single callback function at the appropriate place and hope we get it right.This way the converted Vb code is associated with a Windows %WM_COMMAND or %WM_NOTIFY message and still gives the user a familiar point of departure via the VB event code procedure name.

John
These two quotes are from your first post in this thread.

Just as I was drifting off to sleep it dawned on me what was bugging me about this particular issue. It's not really about the issue. It was the reference to using existing VB code that flipped a switch that I didn't know existed. I gotta learn to turn my head off with the lights.

What if, just trying to convey a thought here, we make a converter so good that VBers continue to write their programs in VB just to run them through the converter, then do the additional things that are not supported in VB? Are we doing them any favors?

The original intent was to create a converter for already written code, but this other scenario seems likely, rather than the users getting comfortable in PB.

Am I just looking for reasons not to go to sleep?

[John R. Heathcote]

Rod,

What if, just trying to convey a thought here, we make a converter so good that VBers continue to write their programs in VB just to run them through the converter, then do the additional things that are not supported in VB? Are we doing them any favors?

Well, IMO, yes. Admittedly I'm referencing my own experiences converting VB to PB so I may be a bit biased, but as I read the many questions posted by former VB users in the PB forums they have the same problem I did, namely, converting the functionality in my VB app to the equivalent functionality in PB. And the central issue to including this functionality is dealing with Windows messages. Having to go back and look at my old VB code is agony, now I'm a PBer through and through. Don't you think most folks will make the transition too?

I agree that VB hides way too much of the underlying Windows message structure from the "VB programmer" so they don't really know how Windows does things or why, nor is this information readily and conveniently available. Since Windows messages are central to a successful PB app the new user wants to know how to respond to these messages. Unfortunately, there is no concordance that shows "you clicked a ListView column header in a VB dialog box, this is how you do the same thing in a PB dialog box". POFFS comes close, but it assumes the user already knows a fair amount of PB with the implied assumption they also know what to look for. I don't think this is a true statement with a brand new user who has just converted from VB to PB.

Another issue to consider is the possibility of our converter being used to convert a commercially developed VB app. In this instance management will want to know, (1) if the VB app can be converted to PB, and (2), how long will it take? If management knows that a commercial application conversion from VB to PB could be done in a couple of weeks to a month using our converter versus six months to a year to do the same thing manually, management might inclined to give the application conversion the go ahead to proceed. And PowerBASIC gets another satisfied customer.

The original intent was to create a converter for already written code, but this other scenario seems likely, rather than the users getting comfortable in PB.

Again, IMO you are going to have this scenario anyway. There will always be some who do not wish to learn and will rely on the converter to provide the solution, we cannot stop this from happening. I think most folks will take the time to look at the resulting PB conversion and see how PB requires the programmer to do things. In this case the converter will also be a learning tool.

Keep in mind that I'm not saying we have to convert VB dialog boxes my way. I am saying there appear to be some additional problems involved with this endeavor that have yet to be discussed. I simply put forth my analysis of the problem and the observation that PBForms does not provide us the level of conversion that we need or desire in the hope that it will stimulate additional discussion. On the positive side, having many of the Windows messages contained in the template files shows the new user how to do things in PB. I don't think this is a bad thing as this idea provides the link between what the user wants to do and how to do it in PB.

If someone else has an idea on how to convert VB dialog boxes I am more than willing to look at it, disgest it, and if it is workable, adopt it.

[Rodney Hicks]

Good answer. I don't even know why it was bothering me. Possibly because I'm not a VB user and I don't know if there are specific things that would help them learn to think in PB. The windows messaging system is a chore for anyone to learn, and if you're used to getting an app up and running without dealing with it, I can see where it might be doubly frustrating.

Regarding PBForms, what it does with a .frm file I find amazing, mostly because there isn't an awful lot of info in the .frm files yet it still sets up a plausible scenario for the user. Any of the .frm files I tried anyhow.

[John R. Heathcote]

Rod,

Good answer. I don't even know why it was bothering me. Possibly because I'm not a VB user and I don't know if there are specific things that would help them learn to think in PB.

You expressed a legitimate question that deserved a response. In fact, you may be a step ahead of everybody since you were not polluted by VB when you started to use PB. You may have a unique advantage over the rest of us.

After having spent considerable time with VB (since version 1.0) it was a chore just to get my head around the PB way of doing things. What helped me was to be able to (eventually) associate the Windows %BN_CLICK message with the VB Button_Click() event code. Once I found that association I was off and running. I think my associating Windows messages with the equivalent VB terminology is fairly representative of what the new PB user experiences.

The difficulty I have is that Windows controls rarely produce or use identical Windows messages when responding to or sending data to a control. This is where the confusion steps in and in this one instance VB does provide a common language interface between controls that allows the user to do rapid prototyping. If we could provide this association in the form of a callback I think it would be a plus for the new user because the light would come on just that much faster IMO.

For example, almost all VB controls have a "_Click()" event or a "_MouseMove()", "_MouseUp()", and "_MouseDown()" events. So why not set up our callbacks with the equivalent Windows messages to handle these "VB events" within the context of the individual controls? Perhaps this could also be a user defined option, turned off by default.

Regarding PBForms, what it does with a .frm file I find amazing, mostly because there isn't an awful lot of info in the .frm files yet it still sets up a plausible scenario for the user. Any of the .frm files I tried anyhow.

I have also tried to import my VB forms to PBForms and I would agree that it does a very credible job with the graphics portion of the conversion, the source code structure IMO is very weak. The user will have to posses good coding skills to reproduce the equivalent VB dialog box functionality in PB. So how is the newly converted PB user supposed to provide that functionality when they have little or no knowledge of Windows messages? Not that it is impossible to do, I think Michael, Stan, Wayne, and a host of others are proof that one can convert from VB to PB. It would be interesting to know how long it took these individuals to become comfortable and proficient with PB in their transition from VB? I'm comfortable with PB, just not very proficient at it yet.

As I stated previously PBForms could do more in source code generation than what it does do IMO. After all, the ultimate goal is to produce a working PB application, and quite frankly, I will take any extra help I can get to help me accomplish this goal.

Since PBForms reads the VB .FRM file to produce the graphics it also has access to the VB event code for that form, so it could use that same event code to parse and construct a more comprehensive Callback function, or individual control callback functions. Since PBForms does not provide this callback source code structure, we have to in order to provide the equivalent functionality of the original VB app in the PB conversion.

How do we do that?

[Rodney Hicks]

How do we do that?

This is I think the major issue in the conversion process and I think we need a lot of recursiveness or at least looping in order to get each of the apples into the pie. (must be dessert time.)

This part is to me more difficult than the COM stuff, but then there's times when whatever I'm working on seems to be the most difficult.

To be entirely honest, I think we might have to try every angle we can think of to see which flows better.

While we're on the subject of difficult things, I've noticed that there has been very little discussion or even mention of how to treat Menus and Accelerators, which may throw another wrench into the works.

My linear thinking keeps bringing me back to PBForms method of providing a callback for each dialog, which is in my mind a step up/down from providing a callback for each control.

A big part of what we're going to have to access in the messaging system we have not yet addressed in terms of VB to messaging system. I think I'll have to generate a couple of more lists.

It would be interesting to know how long it took these individuals to become comfortable and proficient with PB in their transition from VB?

This might be akin to the breakup of a relationship, the sooner you keep the old out of your hair, the sooner you can concentrate on the new. It's the property that you don't want to part with(and they won't) that keeps you tied to the old.

[Rodney Hicks]

http://www.powerbasic.com/support/pb...essages&page=2
Post #20 in the above link is a list of 800+ messages, by item, ie: treeview, toolbar, etc. should any of us need it. No scrollbar messages in it, so there's likely others missing as well.
Posted by Dave Biggs.

John
from your first post in this thread,

My idea was this; instead of having one callback function to handle the entire form, establish an individual callback for each control. This way we could create a template file for individual controls that could contain standard windows messages that we could plug in to the generated PB source code.

I believe, and may be corrected, even stoned for believing this, that your idea of a template file* for each type of control and the corresponding messages is a must have whichever way we go on this issue. That is whether the controls are in one callback or each have their own callback.

*I'm not sure a separate file for each template but a file that is a collection of templates?

[John R. Heathcote]

Rod,

This is I think the major issue in the conversion process and I think we need a lot of recursiveness or at least looping in order to get each of the apples into the pie. (must be dessert time.)

This part is to me more difficult than the COM stuff, but then there's times when whatever I'm working on seems to be the most difficult.

To be entirely honest, I think we might have to try every angle we can think of to see which flows better.

I agree. Since VB dialog box conversion is more complex than module conversion it is important that we select the proper method of handling the conversion up front in our software design. That's why I would like to hear other ideas of how to handle this type of conversion.

While we're on the subject of difficult things, I've noticed that there has been very little discussion or even mention of how to treat Menus and Accelerators, which may throw another wrench into the works.

Accelerators do present a problem, and like you, I've wondered how we intend to implement them? Menus can be built from the VB .FRM file, so I don't think they will be much of a problem.

Post #20 in the above link is a list of 800+ messages, by item, ie: treeview, toolbar, etc. should any of us need it.

I'll take a look at it.

I believe, and may be corrected, even stoned for believing this, that your idea of a template file* for each type of control and the corresponding messages is a must have whichever way we go on this issue. That is whether the controls are in one callback or each have their own callback.

*I'm not sure a separate file for each template but a file that is a collection of templates?

From a purely technical point of view you are correct, it doesn't make any difference if our control callbacks are separate files or found in one file. I was thinking more about code maintenance, adding additional messages, enhancements, etc. Separate files affords us the flexibility to include only those controls that actually appear in the VB dialog box in our PB conversion source code, thereby allowing us to customize the conversion of the fly. Separate files would also help keep source code as small as is practical, thus, producing a smaller executable.