Setting Tab Order

[John R. Heathcote]

I know it's possible to get the existing tab order of the controls on a dialog by using the GetNextDlgTabItem and GetnextDlgGroupItem API functions. Is there a way to dynamically set, or otherwise adjust the tab order at run time, or is this something best left alone?

[Gary Beene]

John,

http://www.powerbasic.com/support/pbforums/showthread.php?t=39987&highlight=set+tab+order

The folks in this thread seem to think it's possible.

[Chris Boss]

The SetWindowPos API function is what you need. You can change the zorder (which affects tab order) of any window with it.

[John R. Heathcote]

Thanks Chris and Gary.

I was tinkering around with using PB Classes to see how easy it would be to account for all of the properties and methods contained in VB controls and to emulate their function in PB as part of the VB to PB converter. So far I am very encouraged by the results. I've managed to emulate most of the basic properties and methods of a VB textbox control to the point that there would be pretty much a 1 to 1 correspondence between PB and VB usage.

Setting the Tab Order in PB (TabIndex property in VB) is one of those properties I've never really used or messed around with except when designing my forms. I think I can recall trying to change the TabIndex property on the fly in my program once, and ending up creating quite a mess of it so I just never bothered with it since then. But VB does allow you to change this property on the fly, so...

VB object/variable scope is the biggest unresolved problem I have encountered so far. VB6 allows variables to be scoped at 3 different levels (PUBLIC, MODULE, and LOCAL) whereas PB only supports 2 levels LOCAL or GLOBAL. I'm thinking that the module level variables in VB could be GLOBAL and named accordingly in PB so the context of their usage would be clear to the user.

[Michael Mattias]

>Setting the Tab Order in PB (TabIndex property in VB

If VB maintains this at the control level, that's a curious design decision. Not that it cannot be done, but seems to me tab order should be a property at the owner window level.

[Cliff Nichols]

VB is a bad example (but I will be the 1st to admit that it was good for "Most Cases" when not knowing what you were doing)

It had the concept of properties and settings and weeeeen a user into programming...so it was a good idea..

Bad Idea was letting mistakes happen and correct them without alerting the programmer they were wrong. (But who could catch all mistakes?) so all in all it was widely accepted.

John, If you think of your comment of

VB6 allows variables to be scoped at 3 different levels (PUBLIC, MODULE, and LOCAL) whereas PB only supports 2 levels LOCAL or GLOBAL. I'm thinking that the module level variables in VB could be GLOBAL and named accordingly in PB so the context of their usage would be clear to the user.

as more in a PB environment then
PUBLIC = GLOBAL
MODULE = GLOBAL
LOCAL = LOCAL
then you can create multiple *.INC files (think of each as a Module) and the rest is either Global, or Local (Then it makes more sense as to how windows sees it)

[John R. Heathcote]

mcm

If VB maintains this at the control level, that's a curious design decision. Not that it cannot be done, but seems to me tab order should be a property at the owner window level.

Quite frankly, its hard telling what VB is doing in all circumstances, I'm not sure if the Tab Order is handled by the control or the form and you can access it from the control level. Like I said, I probably won't mess with it as changing Tab Order is not high on my priority list.

Cliff,

VB is a bad example...

Agreed, VB does hide too much of the underlying code from the user, but I will say that I do prefer VB's event naming convention model over some of the other PB GUI designers as it is more consistent between different types of controls. For example, most controls in VB have a _Click() event which gives you a visual equate of what you want to do regardless of the control. There is some power and ease of use in that philosophy.

as more in a PB environment then
PUBLIC = GLOBAL
MODULE = GLOBAL
LOCAL = LOCAL
then you can create multiple *.INC files (think of each as a Module) and the rest is either Global, or Local (Then it makes more sense as to how windows sees it)

Great minds think alike as this is precisely what I'm doing. I think I will also experiment with Inheritance as most controls have the same basic properties and methods, but that will happen when I get things working and stable.

[Rodney Hicks]

For example, most controls in VB have a _Click() event which gives you a visual equate of what you want to do regardless of the control. There is some power and ease of use in that philosophy.

Quickly off the top of my head, this might be emulated via a macro, to help users with the adjustment in philosophy.

[John R. Heathcote]

Rodney,

Quickly off the top of my head, this might be emulated via a macro, to help users with the adjustment in philosophy.

I think there are several ways to do this, MACROs are certainly one way, another would be to subclass the control and trap specific Windows messages in the Callback that point to common events. The problem with VB control/objects is the methods and properties are general to the object whereas events are specific to the control/application. At any rate I'm just trying to see if this idea will work and how easy (simple?) it will be to generate PB source code from the VB project.

[Paul Squires]

For example, most controls in VB have a _Click() event which gives you a visual equate of what you want to do regardless of the control. There is some power and ease of use in that philosophy.

I agree that on face value that molding all controls to common "event" names sounds like a good idea, however, I personally believe that it is a short term and limiting move. VB is not PB, rather PB is more like C especially in terms of the message handling.

As such, the PB programmer should be learning the underlying syntax as created by Microsoft themselves for the Win API. BN_CLICKED notification versus _Click, etc... Once the programmer gets into that frame of mind, then the sky's the limit on their knowledge.

There is so much documentation available for each type of visual control available in Windows. Why would one want to bastardize that documentation by creating yet a whole other level of indirection? It doesn't make a lot of sense.

Granted, I used VB for *many* years prior to PB and I know that it does give the programmer a level of comfort, but that comfort comes with a price. When I changed my mindset from PB to WinAPI, my whole programming world exploded with new possibilities and endless ideas. No longer was I constrained into the "VB model".

I'm not trying to be antagonistic, I'm just relaying my personal experience since moving away from VB about 8 or 9 years ago.

My personal belief is that programmer education is a better investment than re-engineering the programming model.

[Michael Mattias]

At any rate I'm just trying to see if this idea will work and how easy (simple?) it will be to generate PB source code from the VB project.

Isn't there some kind of group project to do just this which has been underway for a while?

[Michael Mattias]

>then you can create multiple *.INC files (think of each as a Module

That's very misleading, Cliff.

In the PB environment it is usual to use the word 'module' to describe 'all code compiled at one time into a single executable file."

e.g, one compiled module may utilize many *INC files.

PB's GLOBAL scope applies to the current module -as defined above- only. There is no "share a variable name , by name, across modules" facility in the PB compilers for Windows.

[Chris Boss]

The problem when moving from Visual Basic to PB (using the API), is that VB is a GUI engine and not simply a compiler. Often there is no direct one to one relationship between something in VB and the API.

One good example is that the controls are not standard Windows controls provided by the operating system. They are likely superclasses of the standard controls, which gives VB access to the controls window procedures (superclass is a new class based on an existing one and not simply subclassing).

For example a VB Button control is not of the "button" class.

The actual class name for VB 5.0 Pro is:

"ThunderRT5CommandButton"

Wow, what a mouthful!

Thats a definite clue the control is not a standard button control.

This means VB can impliment features beyond what is normally done when using the API.

VB forms are also a unique window class to VB.
Likely they poll the controls (enumerated) to get their current tab order number and then the form sets their zorder.

This creates problems when trying to convert VB code to PB (API).

VB may also impliment extra features not found in the API directly, which makes it even harder to convert to PB.

The runtime (DLL) in VB is about 1.4 meg in size for VB 5 and 6. Thats a lot of code! VB's runtime is a GUI engine. The compiler compiles code to calls to the runtime and it is what that runtime is doing that is important, not what the compiler compiles to. While most logic commands and math are likely compiled directly to machine code with direct calls to the API, I would venture to say that most of the GUI commands (events, methods, properties) are compiled to calls to the runtime.

To make matters worse, is VB's dependence upon COM. Rather than lots of procedure calls being made to the runtime, likely much of the GUI command set are COM calls. COM objects are created and then calls are made via COM to the objects.

The best one can do in conversion from VB to PB is to emulate VB's tasks. Don't think you can make a direct conversion from VB to corresponding API calls.

For fun, lets look at the VB runtime using the Microsoft Depends Utility.

Depends can load any EXE and find all its dependencies (DLL's) and what calls are made from the EXE to the DLLs. It won't though show COM calls, so you lose a lot there.

Lets look at some of the VB runtime function names:

MethCallEngine
ProcCallEngine
rtcAppleScript
rtcCreateObject
rtcDoEvents
rtcQBColor
ThunRTMain
TipCreateInstanceProject
TipInvokeMethod
VBDllGetClassObject

Doesn't sound like the API to me !!!

VB is a GUI engine.
It is important to view it as such.

Now to matters even worse, many of the advanced controls (Common Controls) are not even in the VB runtime, they are OCX's. Those OCX's (activeX) are quite large and likely they are not simply wrappers over the API passing on calls to the API. Likely there is a lot of unique code within those OCX's which impliment features which do not have a direct one to one relationship to the API.

This is why when one moves from Visual Basic to Powerbasic, it is often better to simply "forget" about all you learned with VB and to start learning PB from scratch (and the API). If your desire is to write real API code, then forget about VB. You have to immmerse yourself into the API and how it works. Not a fun prospect for many a VB'er, but sadly it is necessary.

[Michael Mattias]

Not a fun prospect for many a VB'er, but sadly it is necessary.

Sad?

Since when is learning new things a 'sad' occasion?

[John R. Heathcote]

Paul,

I agree that on face value that molding all controls to common "event" names sounds like a good idea, ...

It is.

...however, I personally believe that it is a short term and limiting move.

Not necessarily. I wrote some very successful and complex civil engineering apps accessing AutoCAD, Excel, Word, and MOSS (a surface modeling package) using the VB event model. While on occasion I did have to resort to making some API calls to keep my app the top most window, things like that, those occurrences were minor. I would say that 99.8% of the time the VB event model served me quite well and did not inhibit or limit me in any way.

Take a look at the VB event model and ask yourself how many times do I have to realistically go beyond what is present there? While there may be occasions where you have to deviate, I submit that most of the time the VB event model will handle the processing situation quite nicely.

That experience lead me to the observation, how many of the specialized Windows messages does one really need to use, or do you end up using the same ones over and over again? And if you use the same Windows messages over and over again, why can't they be consolidated into one common event for each control? VB did that.

Remember having access to all of the various Windows messages can over complicate the issue as well and that aspect comes at a price too. The new PB user wants to know what specific Windows message is fired from a specific control that is used to accomplish a specific action like a mouse click? This has always been my overall problem with Windows because let's face it, Windows contains many different messages for different controls that accomplish the same thing. Seems to me the design of Windows, or rather the lack of it, is a big part of the problem too.

VB is not PB, rather PB is more like C especially in terms of the message handling.

I don't disagree, but the overriding comment I hear from former VB developers is what Windows message accomplishes a specific user action? Why does Windows make such a simple action like a mouse click so overly complicated? Couldn't this be a little simpler than it is? Questions I've asked myself many times. Windows gives very little clues about this, VB cuts through that bafflegab and does give you something that is workable. While the VB event model may not be the most perfect or even the absolute ideal solution, it is workable and therefore usable.

Yes, this is done at a price, but as a developer I can make that decision whether I think it is worth it to work within that framework or not.

I think you also have to remember that many developers are pressed by the constraints of time, I know I had this limitation placed upon me. My supervisor wanted to see results, he wasn't too keen on me doing days of research trying to find out how to process a mouse click type of event for a listbox and/or listview control.

There is so much documentation available for each type of visual control available in Windows. Why would one want to bastardize that documentation by creating yet a whole other level of indirection? It doesn't make a lot of sense.

But it would be nice to have a document for the new users that said if you want to process a VB mouse click event for a listbox, this is the message(s) to use and you place that code in this callback at this location, type of thing. Again, the new user is trying to equate what he currently knows and extrapolate that into another different type of programming model.

I know if I want to do this I would take a quick look into the code Firefly generates, but even then, sometimes it is not readily apparent what Windows messages are referenced or where the specific code is located to do specific things. Source code comments could be of tremendous help here (hint, hint).

My personal belief is that programmer education is a better investment than re-engineering the programming model.

Would agree, up to a point. I think you have to remember most of us consider you to be an expert in PB and the Windows API as is Chris, Jose, Dominic, Michael and a host of other regular contributors to these forums (sorry if I missed anybody). As such you have achieved a level of expertise that the rest of us don't have and probably will not achieve, not that we don't have the desire to learn.

There are practical limitations to consider, the constraints of time performing our jobs prevents us from achieving this goal, for example. I was paid to design highways, not to write software. It was only after I gave my supervisor a demo of what my software could do did he give me the go ahead to continue developing it, but only for about 1 to 2 hours a day. So I ask you, how extensive a level of PB and Windows API knowledge can you amass and retain when you are forced to concentrate on other things for most of the day?

[Paul Squires]

Hi John,

Thanks for taking the time to respond to my points. I appreciate it.

I read through your response and I can honestly say that I can't disagree with your point of view at all. Hell, I had the *exact* same point of view as you at one point.

One thing about your post that resonates with me is the information overload vs. time vs. productivity issue. I hear it all the time from customers that email me personally. I feel the pain and certainly empathize. One thing to remember is that the more bite sized pieces of the api that you know, the easier that your programming will become and the faster that you'll be able to accomplish it. That I promise you.

I think you have to remember most of us consider you to be an expert in PB and the Windows API

Thanks for the vote of confidence - you did put a smile on my face. I assure you that I am no expert. Far, far, far from it. The Dominic's, Jose's, and Patrice's of the world have forgotten more about the api than I know. My skill is that I know how to define a problem and then seek the information to solve it. Over time that has helped me learn. I didn't one day sit down and say "Today's the day that I learn the Windows API". Everything takes time and luckily for me I am not pressured on a day to day basis to produce programming results in my "day job". If I was, then I could relate totally to your situation.

I can say with quite certainty that the key is education and how that education is delivered to people. Over the last 8 years or so I have read countless posts here about the inherent difficulty of the Windows API. It is hard (a better word would be frustrating) - to a certain point because it is not presented in PB specific context and it is not specifically "problem solving" oriented. It is just a bunch of functions and descriptions. The usability factor is missing.

There is stuff in the api that I have never touched, nor will I probably ever touch unless I have a need to. For example, there is so much about low level graphics stuff that I don't know. However, I do know how to do the basics of manipulating GDI via WM_PAINT but it is certainly not magical nor mystical. I'm sure that I stole the knowledge from Borje's code a long time ago or dug it out of POFFS.

As such you have achieved a level of expertise that the rest of us don't have and probably will not achieve, not that we don't have the desire to learn.

You should never sell yourself short. When I started, I looked at Borje, Semen, MCM, Lance, Tom, Hutch, (etc) and said to myself that I am way over my head. It is only human nature to feel intimidated especially in a forum where everyone wants a level of professional significance with their peers. I had used QuickBasic and PBDOS for several years and started Windows programming using VB3/4. I finally switched to PB/DLL from VB6 once I heard that PB/DLL could actually create EXE's in addition to DLL's. If you go back and look at my early posts... well, let's just say that I was not the leading candidate to be a PowerBASIC Engineer. My background is business (accounting, auditing, management, etc.), not programming. I hacked around in VB just enough to be dangerous

If I were to say that I could show you everything that I know about Windows programming (well, the practical everyday stuff), you'd be interested right? You be interested if it was packaged right and delivered correctly (not just an endless boring stream of function names and their definitions). You'd be interested if you could learn in small, usable, chunks that you could apply to your everyday programming and that at the end of the learning that you would see a noticable improvement in your windows api knowledge. Such a product is not too far off in the future.... <wink><wink<nudge><nudge>

Programming for me is a hobby. Yes, a hobby. I love my hobby and wouldn't trade it for the world. It fulfills me and allows me to deal with brilliant people from all over the world. Having said that, I work 9 to 5 like most people so programming is only available to me when I can get at it.... granted, I get at it a lot.

I hope that people read this thread and say to themselves that if Paul Squires can do it then I sure as hell can. Because that's the reality of it. Everyone can do it. It is proven every single day in these forums. I could name several people right off the top of my head that maintained persistence by asking questions and searching for knowledge. I can now see that tenacity paying off in the content of their current questions and how they give respond to other's posts. It is really cool to see us all grow as programmers.

.

[Edwin Knoppert]

In VB6 there is private and public in a module like:

Private hhh As Long
Public hhh2 As Long

Only Module1.hhh2 can be changed from the outside.

In .NET C# there is no module (VB.NET does have though) but you can create a static class.
No need to dimension that one.

In PB this could be a global interface being instantiated on load.

[Chris Boss]

John,

If it is necessary to emulate VB, then there are two approachs that will work but will require a good bit of work.

As I noted before, VB is a GUI engine, not simply a compiler.

To emulate VB requires that you build your own GUI engine with PB, and then code using that GUI engine.

(1) Build a GUI engine which processes all the windows messages to the Dialog procedure and then convert those messages into universal events. Build your own interface for passing those messages to your control event routines. Use macros to emulate many VB commands.

(2) Build a complete GUI engine using PB's new Object (OOP) commands. You will have to create objects for nearly everything (forms, controls, etc.) You won't create forms and controls like you would normally using PB, but instead you would create objects and then access those objects using methods and properties. This is quite doable, IMO and possibly worth the effort. It is not an overnight job though and there is no easy way, other than writing a good sized GUI library of objects.

It may be difficult to fully emulate the VB form format, since form files contain code in a syntax which is not very compatible with PB syntax, The event routines are not a problem, but the form definition code may be difficult. You would have to use macros to emulate the BEGIN/END stuff for form definitions.

I think the best approach would be to write a converter app, which converts difficult code to something more palatable to PB coding style and then emulate as much of VB syntax as possible via GUI library (whether macros or objects).

[John R. Heathcote]

Paul,

Thanks for your kinds words. I appreciate the fact that you are not unsympathetic to the plight of the masses.

One thing to remember is that the more bite sized pieces of the api that you know, the easier that your programming will become and the faster that you'll be able to accomplish it.

I tend to agree and I do find that I am retaining more and more of the Windows API as time goes on, my recent concussion notwithstanding, but I would still classify myself as an armed and dangerous PB coder, believe me I can GPF like no other.

Perhaps I should clarify myself a bit. I'm not suggesting that PB should be VB like in all cases. If you have the coding experience, desire, inclination, and a good understanding of Windows messages then delve right into the Windows API and go to work. I will always be impressed by the folks who can show this level of expertise.

Some of us OTOH need to be immersed in the VB/PB transition for a longer period of time to get our head around the programming concepts of PB, Windows messages, callbacks, etc. After coming from an old FORTRAN IV/77 procedural coding background PB was quite a culture shock for me. I felt then as I do now there should be some transition tools available to ease the pain and increase the programming comfort and confidence level.

Chris,

Thanks for your thoughts as well.

I came to the realization some time back that I really do not want to emulate VB in its entirety, I think such an endeavor would be pointless and totally unnecessary, instead, I think I need to provide just enough VB emulation to get the style, flavor, and functionality of the VB app ported over to PB.

So far I have discovered a combination of control subclassing, plus PB objects to handle the ongoing VB methods and properties in the app, plus responding to specific Windows messages generated by each control to handle the control events I can emulate about 80 to 90% of the VB model which should be enough to retain most of the VB app functionality, but still allow the user to understand PB concepts (the education aspect that Paul mentioned). Part of this design would allow me to have a library of pre-coded routines/objects that I can plug into the PB conversion as need be.

Now there will always be some VB issues that can't or shouldn't be converted to PB because of the value of diminishing return, so I'm not even going to try to provide that type of VB functionality in PB. The best I can do at that point is to make the user aware of the issue and perhaps outline some coding strategies to overcome the problem.

Furthermore, I'm coding my objects using the vTable calls so they are as fast as they can be. That fact alone dictates some departure from the VB model, but is one that I think is worth it in the long run to the user. But even with this departure it is truly amazing the amount of VB like functionality you can put into a PB object.

[Cliff Nichols]

As a "VB Refugee" I can feel for both sides of the fence. (and maybe even the middle-ground)

VB gave the ease of clicks and points and general stuff (pretty good for weening a new programmer), but decided to make it harder than needed (if not impossible) for you to do harder concepts for developers that truly wanted to know "Whats under the hood"

Like John has said, there is not 1 to 1 but I think PB has done a WONDERFUL job with DDT (being as close to VB as I can think of in a VB mind)

and yet ween you to API (to me the core of the operating system, unless you feel the need to learn assembly, and then you are on your own cause you started from the wrong base of understanding)

I started out from a pure VB concept, and then learned some minor API (for subjects that I could not do in VB) but having done them the transition was maybe easier (because I wanted to KNOW why I could not just call some property and use its value)

MCM is TOTALLYYYYyy incorrect with

>then you can create multiple *.INC files (think of each as a Module

That's very misleading, Cliff.

From a VB6 point of view I would think its spot on. (Re-Use code code rather than every function recreate the same code) but you have to obey the "What I call hidden rules of Windows" to be invalidated)

Time vs KNOWING!!!! is the problem of every programmer.

Sure you may have some expertise in a area, but you can NOTTTT know everything about anything.

Probably why I love PB so much (although I fought it for several years, cause VB let me beat time constraints, and I could understand the language)

To me the following holds true:
DDT = VB basic
DDT (with research) = VB tougher jobs
SDK = API (Things we should have been taught in the 1st place rather than VB, but time did not allow)
Assembly = (Things we neither have the time for, nor remember from before "Windows" being invented) but well needed from time to time

Basic in general.....(At least I can read it and attempt to follow it 20 years after it was written, and make it productive again)