Tab Order List

[Martin Francom]

I am finding that the way the Tab Order is displayed in the Firefly Workspace is not as helpful as it could be.  I have several forms that have  lots of controls on them.  If the Tab Order listing could make it a bit more clear just looking at the list  which items have "TABSTOPS" and which do not. 

Unless I am missing something, currently you have to click on an item to be able see whether or not it is a TABSTOP.   And the other thing that aggrevates me is that the TABSTOP and Non-TABSTOP items are (or can be intermixed. Making it even more confussing what is and isn't a TABSTOP.

Would it be possible to make the list in such a way as to allow the programmer to just look at the list and be able to see which items are TABSTOPS and which are not?

One possible solution would be to color the font of a TABSTOP item differently fron that of a Non_TABSTOP item.

Another possible method could be to have all  TABSTOP items at the top portion of the listing and all the Non-TABSTOP items on the lower portion of the listing with a separator line separating TABSTOP items from Non-TOPSTOP items.  So that it would be easy to identify which are which.

[Marc van Cauwenberghe]

I would like this kind of distinction also. Maybe something in front of each control.

Marc

[Roger Garstang]

Yeah, that was posted in the original thread where he talked about it too.  It would also be good to be able to have multiple selections...but the logic for moving multiple selections would be a mess...especially if ctrl selected and not a column of values with shift selection.

[Paul Squires]

The Tab Order dialog now displays all controls in the order that they will be created during code generation. I guess that some type of visual cue would be good to differentiate the tabstop controls from the non-tabstop controls. Not sure what the best approach would be. Maybe an icon in front of the control name or a different font for the line..... I'll probably try it both ways to see which one looks best.

Another possible method could be to have all  TABSTOP items at the top portion of the listing and all the Non-TABSTOP items on the lower portion of the listing with a separator line separating TABSTOP items from Non-TOPSTOP items.  So that it would be easy to identify which are which.

I can't do that because it would defeat the purpose of the taborder redesign which was to allow the programmer full control over the order in which the controls are created during code generation.

[Paul Squires]

Okay, I've made a change to the TabOrder list. It is now an ownerdrawn listbox with "checkboxes" for each line. Clicking the checkbox acts as a toggle for the WS_TABSTOP windowstyle for the control. I have been playing with it for a hour or so now and it seems pretty intuitive.

Attached is a screenshot.

If nothing else changes, then this new change will be in v3.07.

[Roger Garstang]

Cool, I like it.  I know you probably spent some time making it because those styles of listboxes are a pain...but wouldn't it have been easier using a listview?  It has the functionality built in all you have to do is turn off the header.  Or, you could even keep it on and have two columns with one for type and/or name and one for the text to line them up better and make a faster read.  This would allow for further enhancement too where you can have an ownerdata list stored in an array sorted by tab order that would allow for sorting/displaying the list to order by type or text, selecting multiple items, etc. (All with the array still stored by tab order which you could show in that order again by clicking a restore/show order button or even have them numbered in the list so that column can be sorted by)  All kinds of cool options could be done then. First thing comes to mind is sorting by type and shift selecting all Labels and removing the style. Could have an image list with two images to toggle between too instead of a check (Or the imagelist already made from your control tree to show the control types). They could highlight all and hit spacebar or a button and toggle them all, etc. I have code used in other apps for all but dragging columns if needed...I don't like dragging columns because it isn't handled right and they don't really move. Setting the first column to a number would be good too since there is a bug in Auto-Sizing the first column in an Ownerdata Pre-Vista.

[Paul Squires]

Maybe in the long a listview would be better but implementing the ownerdrawn listbox only took about 10 minutes. Actually, most of the time spent was creating the check box and blank check box icons. I easily copy/pasted the other ownerdrawn code and added a call to DrawIconEx to display the icons. Added a test for when the checkbox is clicked and called the existing code that I wrote previously for setting/unsetting the WS_TABSTOP style.

[Martin Francom]

Paul,
   With this new approach, will it be possible to move all the checked items to the top of the list (keeping them in TAB order)  and moving all the non-checked items to below the checked items?

[Paul Squires]

Paul,
   With this new approach, will it be possible to move all the checked items to the top of the list (keeping them in TAB order)  and moving all the non-checked items to below the checked items?

Unfortunately not.

[Martin Francom]

Paul,
   With this new approach, will it be possible to move all the checked items to the top of the list (keeping them in TAB order)  and moving all the non-checked items to below the checked items?

Unfortunately not.

Paul, from the look of the image you supplied, it appears the items can be re-arranged manually to do exactly what I am asking.   So, if that is true then why is it not possible for a button to be on the form to automate the process so that when the button is clicked the checked items are moved to the top of the list and the unchecked items moved to the bottom of the list. 
  I don't understand why that is a problem?   (Given the fact that it can be done manually.) 

[Paul Squires]

There are a couple of reasons why the tabstop and non-tabstop controls are mixed together the way they are. There was a thread a while back where Roger Garstang indicated the importance of being able to specify exactly the order in which the controls should be created in the final code generation. Based on his application I could easily see that it was imperative to be able to specify that, for example, a certain Label come before a certain TextBox. It has to do with accelerator keys and and focus.

In your situation, it probably makes no difference that non-tabstop controls get created after the tabstop controls are created. In that case, I see you point 100% and would certainly agree with you.

In addition, the order of creation also affects the zorder in which controls appear on screen. If you need to have one control display in front of, or behind, another control then you need to be able to have full control over the order of control creation. The zorder can be independent of the tab order so you need to have full control over the position of controls in the order of creation.

So, the question and answer is a little more involved than it seems on the surface. 

[Roger Garstang]

Speaking of my initial problem...did we ever figure out why up/down controls are behaving different than FF2?  In FF2 I could place them anywhere and when they auto-buddy they connect to the controls by tab order and automatically position themselves and resize the buddy control (usually a textbox)...they also resize themselves to be taller if needed, etc.  In FF3 they autobuddy and resize the buddy, but don't go to the position they are supposed to...they instead stay where I have them placed in the IDE (Which even if I get them to place right still looks weird and if they resize vertical they place different in the IDE than runtime).  I'm guessing it is because of an extra SetWindowPos FF3 is using at the end of every control created.  What is the reasoning for that being there?  When the controls are created they already have their position and size parameters.

[Martin Francom]

Paul,
   Not to beat a dead horse, but I am still a bit confused.  Are you saying the order of the controls list in the list box must stay in the exact order in which they where created?
    If so,  what are the move UP and DOWN arrows for?   And by using them doesn't that change the order in which the controls appear in the listbox.  That's all am asking is to have a button that would sort the controls in one step rather than have to move the items one by one.   
    If re-arranging the items in the listbox with the UP and DOWN ARROWs doesn't cause a problem then why would automating the process cause a problem.
    If  re-arranging the items in the listbox with the UP and DOWN arrows DOES cause a problem the why have you not removed the Move UP/DOWN arrows? 

   What you're telling me doesn't make sense to me.  Either I'm not understanding you or you're not understanding what I want the "SORT" button to do. 

   For those that want the order of the items to remain in the order EXACTLY like they created the items of the form.  The solution is simple Don't use the UP or DOWN Arrow buttons to move the items AND Don't click the SORT button.   Seems like a simple solution that makes for a win-win-win solution.

[Roger Garstang]

Not that they must stay in the order they are created...but that they are listed in the order they are created/will be created (Without changing them it is the order you add them to the form, so usually it will need changed unless you add controls in the tab order you want).  It is fine to move them.  Just remember if you move all your labels to the beginning and use the & in the label caption to underline a letter of the label to allow holding alt+that letter to jump to it that it jumps to the label if it is a tabstop or to the next control in the tab order if label isn't a tabstop.  Usually you do this and put the label in order with the textbox it goes with after it for easy keyboard navigation (Buttons/Options/Checkboxes can also be activated this way with their caption).  If you move them all to the beginning and turn off tabstops for them then hit their alt+letter [if defined] then the next control for all labels will be the first control after the group and the same for all labels.

I'm guessing you don't use the alt+letter navigation and just want to move them there to group them and make it easier to read.  This would be fine since they are not tab stops it doesn't really matter where they are put.  Although a hide option in the future would probably be better to keep them in the order you want but just filter the list to not show them.