CWindow problem adding 2nd button

[Paul Elliott]

Thanks.  It works.

Now I can put my buttons back where they belong.

Just curious.  What was the other method?

[José Roca]

The other method is to make the tab pages children of the main wndow instead of the tab control, but this implies to redesign several things.

I designed CWindow to ease SDK programming when coding by hand, not as an OOP-like alternative to the existing Visual designers. I needed it to test that my headers and wrappers worked both as ansi or unicode and High DPI, and was also useful for testing features such classes and dead code removal during the beta testing of PB 10/PBCC 6. It can be used both to build a full GUI or use only some of its methods to ease the embedding of some controls, such I have done recently in the PB forum to embed OCXs or the WebBrowser control in a DDT application.

I leave visual designers to experts like Dominic or Paul and use CWindow to experiment new things without having to wait until these tools are ready. This doesn't mean that CWindow is useless, but most users are going to design his GUIs with a visual designer, not by hand. Anyway, a complex tool like the CSED editor has been written entirely using CWindow, so it means that is powerful.

[Paul Elliott]

José,

Ok, I'll take the easy way out.

I was just making another GUI front-end for the Code Formatter.
I had already taken the Phoenix GUI version and converted to DDT. And coded the tab pages
the same way that PB's Tabcontrol sample program did. Simple copy/paste and minor
changes for the different syntax.

Then I decided to try your CWindow routines. Did a copy/paste of the DDT code and minor
changes to the different syntax. And it worked without a problem until I added the buttons.
Minor changes or new controls I can add without any problem. If I ever do a major reworking
of the GUI then I can always use PBForms to lay out the controls and just copy/paste the
new stuff. No problems.

Thanks for all your work.


And 

Dominic,

Thanks to you for your help.

[Theo Gottwald]

Thats why i like the new Firefly 3.5 - its based on CWindows and as a result the results are at top of what we can expect from any VD.
Let's see how Phoenix 3 will be able to top that.
Personally i hope that CWindows will get a new standard for VD in PB. This would mean that all PB Dialogs will be dpi-aware.

[Dominic Mitchell]

Thats why i like the new Firefly 3.5 - its based on CWindows and as a result the results are at top of what we can expect from any VD.
Let's see how Phoenix 3 will be able to top that.
Personally i hope that CWindows will get a new standard for VD in PB. This would mean that all PB Dialogs will be dpi-aware.

You lost me.

Dialogs in PB would be high DPI-aware if you use dialog units to create them and add the
relevant manifest. You don't need CWindow or its derivatives for that.
The same goes for Phoenix 2.0 except that either pixels(resolution independence set)
or dialog units can be used.

[Paul Elliott]

He lost me too.

It will be years before I build anything that high DPI-aware ( not sure what it is ).
I'm still using crt-monitors.

FF is still building tab screens that same way that it did back in v1 ( right ? ).
Not doing the design right on the tab page. You have to create a whole new dialog/form
to do the design on and then show/hide them according to what you want to see.
A step above PBForms ( maybe ) but PB can do the design right on the tab page itself.
No extra dialog/form need be created. And this capability has been there since v9.

Frankly I haven't seen any FF v3.5 code. The test version won't let the user see the compilable
code.

And it is no problem going from straight PB code to Phoenix to CWindow and back.
Just minor differences in the syntax.

[José Roca]

Me too

I always have stated that it was designed to ease SDK programming when coding by hand. If certain parts can be useful for a visual designer, this is an added bonus.

Dialogs in PB would be high DPI-aware if you use dialog units to create them and add the
relevant manifest. You don't need CWindow or its derivatives for that.

Indeed. DDT dialogs have however a couple of small problems caused by rounding since they use longs instead of singles.

FF is still building tab screens that same way that it did back in v1 ( right ? ).

Of course. A method like InsertTabPage is useful when coding by hand, but how are you going to use it in a visual designer? Same for classes such CAfxImageList. In a visual designer you expect to do it by drag and drop or with a helper dialog.

All this comes for lack of understanding of the purposes of my code and also of the problems involved with High DPI.

BTW I have just added two changes: to CWindow I have added properties to allow to set the class name to other than the default; otherwise, you couldn't use this class to build GUIs in DLLs if they where going to be used by a program build with CWindow. The other is a new function added to Windows.inc:

Code Select Expand


' ========================================================================================
' Retrieve the value of the UseDpiScaling setting (Vista/Windows 7).
' ========================================================================================
FUNCTION AfxGetUseDpiScaling () AS LONG

   LOCAL hr AS LONG
   LOCAL hKey AS DWORD
   LOCAL wszBuff AS WSTRINGZ * 256
   LOCAL dwType AS DWORD
   LOCAL cbData AS DWORD

   IF RegOpenKeyExW(%HKEY_CURRENT_USER, "Software\Microsoft\Windows\DWM", 0, %KEY_QUERY_VALUE, hKey) = %ERROR_SUCCESS THEN
      IF hKey THEN
         cbData = SIZEOF(wszBuff)
         hr = RegQueryValueExW(hKey, "UseDpiScaling", 0, dwType, wszBuff, cbData)
         RegCloseKey hKey
         IF hr = %ERROR_SUCCESS THEN
            wszBuff = EXTRACT$(wszBuff, CHR$(0))
            ' // Extracts DWORD from string
            FUNCTION = CVDWD(wszBuff)
         END IF
      END IF
   END IF

END FUNCTION
' ========================================================================================


If it returns false, you don't have to do scaling even if the DPI is different to 96. This happens when the "Use Windows XP Style DPI Scaling" setting in Vista/Windows 7 is checked.

I wish people will try to learn programing instead of receiving replies like "I don't want lo learn that. I buy tools to not have to learn. I expect that they do all the work for me."

[José Roca]

I will post them soon after testing. I hate to post a new version five minutes later just because I have missed some small detail. At this moment, you don't need them unless you want to build a GUI in a DLL that is going to be used by a CWindows application.

[Paul Squires]

FireFly is by no means perfect or the be-all-end-all tool for PB programming. It does what it does and does it pretty well. So what that Tab Controls are created using independent dialogs - it is logical and easy to implement for the user. It is easier than hand coding it and has worked very well for many years. Maybe the Visual Basic approach is easier where you click on the tab and draw controls directly to the embedded dialog but that's not the route I chose because it did not model the SDK approach very well and at the time added a degree of complexity to the FireFly designer itself that I did not want to tackle.

I am in the process of making FireFly and programs it creates High-DPI aware. It is through the use of Jose's cWindow class and his extensive guidance and help that is making this possible. Once I tackle that hurdle then I will try to get the unicode compatibility implemented. I don't program half as much these days as I used to so it takes me longer to get these types of things done. At one point I was programming 6 or 7 hours a day every day...these days, it's lucky I do that each week. Funny how life changes and your passions for things change.

I'm looking forward to seeing Dominic's new Phoenix and every new PB product and 3rd party product. For me, programming and providing FireFly as a visual design tool is not about being the best choice to the detriment of anyone else, or about making the most money, or having the most number of customers, or as some type of ego boost. In the long run, FireFly is just a very small piece of software in the PB universe. I have no desire or motivation to push FireFly through negative advertising of any other competitor's product whether that be Dominic, Edwin, Chris Boss, or PB Forms itself. Everyone has their own style of promoting their software and I learned a couple of years ago that using certain words or phrases certainly rubs people the wrong way. Although done with no intentional malice, it certainly changed my relationship with persons I admire and respect.  Since then, programming has lost its lustre. So, I don't engage in debates about SDK, DDT, EZGUI, Phoenix, etc anymore. When people email me asking me to "give me a sales pitch as to why I should choose FireFly over XXXXXX", I simply tell them to read the material on the website and download the demo and try it for themselves.

To be honest, these days I mostly enjoy dealing with customers in the FireFly support forums and helping them use the tool effectively. Learning new approaches to programming and seeing what the Jose's and Dominic's of the world are doing with low level COM is very inspiring.

[Paul Elliott]

Paul Squires,

I meant nothing against you or FF. I was very happy to use the method of creating a form/dialog
to create the tab pages. And after I finally got it thru my head what I needed to do to switch
tab pages under program control, things went well.

I only found out about PB's new way of creating tab pages when I tried to help someone on the
PB forums. I did think that it might have been fairly simple to do with a visual designer by drawing
on the real tab ( or at least something of that size ) and creating a small bit of code to do the
creation on the real tab page at run time.

For the past several years all my programming has been small programs for personal use.
I've made due with PB Forms and only occasionally used FF or Phoenix. At times I wish I had a
use for FF v3.5 but just can't justify it.

I didn't mean anything negative by my remarks.

[Paul Squires]

Hey Paul, no offense taken my friend. None at all. It's all good. 

[Christopher Boss]

a visual design tool is not about being the best choice to the detriment of anyone else, or about making the most money, or having the most number of customers, or as some type of ego boost

Well said !

In my own case I have found that my own EZGUI is not for everyone.

When a potential customer emails me I find it important to ask them questions about what they are trying to accomplish and what tools they are familiar with so I can determine whether they are well suited to my own product or someone elses. I have at times strongly suggested to some that for example FireFly may be better suited to their goals and style of programming. rather than my own tools.

Now of course comparisons between products is necessary at times, simply for the sake of defining ones potential market better, but this does not make one product better than another for all people.

In my own case I have found that there seems to be specific mindset to those of my customers who are most productive with my software. I really don't want customers who buy my software, only to shelve it and not be happy with it. That serves little purpose. They waste their money and I don't have a customer who will continue to support  my business in the future.

For example I find that it is most difficult for my software to please those who came from a Visual Basic background. Definitely not well suited to using EZGUI ( a few might be). If a potential customer even mentions Visual Basic, I am more likely to kindly push them towards FireFly. Paul has a done an excellent job of the integrated environment (visual design and code editor together) and also he supports ActiveX controls.

On my forums I recently added a topic of comparing FireFly and EZGUI and in good conscience I had to preface the discussion with a nice plug for FireFly and some reasons why someone may prefer it over my software and even a link back to his web site. The comparisons I make on my forum are simply to differentiate my tool from Pauls so those who do buy mine are doing so because they see specific benefits to them personally by using it.

Powerbasic is actually a strange development tool in that their are so many different ways one can use it. There are the DDT users, SDK coders and EZGUI users. Even among SDK coders, there are significantly different styles of coding. There are those who like to impliment as much OOP as possible and those (like me) who tend stay far away from OOP.

The background of each PowerBasic user is also vital in determining which route they may take when using PowerBasic. Did they come from a DOS basic background, from a Visual basic (not dot.net) background, from a Visual Basic (dot.net) or C# background ? Are they moving from the console compiler to the Windows compiler ? All of this determines which development tool will best suit their needs and mindset.

Now in my case, strangely enough, some of my best and most productive customers come from a DOS background and started developing GUI apps using my software. Some of the least satisfied came from a Visual Basic background. Now each group is not all inclusive, since some VBers like and use my software, but I do find trends where a specific group or mindset do better or less better with my tools.

I really think the key is to find out which types of programmers do best with ones tools and to reach out to them. The worse thing would be to have people try to push each 3rd party developer to make their tools more like the other guys. I have some past customers who used EZGUI for a time and the switched to FireFly. Rather than for me to try to emulate FireFly more in my software to try to get them to come back to using EZGUI, I find it better to recognize that for their needs and mindset and programming experience, that FireFly is simply the best product for them.

We don't need all the 3rd party tools to be more like each other. Each has their target user base and benefits to those users. Actually the more each 3rd party tool differentiates itself, the better. There is no "one fits all" when it comes to such tools. It would be better that such tools be uniquely different, but more productive for their user base, then to have them merge and be more like each other.

So Paul, keep doing what you are doing. You have a very happy and productive user base so concentrate on pleasing them.

I don't know if some PB users realize this or not, but some times the most difficult to please users of our products are the ones who buy all of the 3rd party development tools (ie. multiple visual designers). We appreciate the support, but when a programmer keeps switching between these tools it is easier to see how one differs from the other and then to harp on those differences trying to push the developers to be more like the other (I have no specific person in mind, but this is a generalization only).  While we may appreciate the feedback, too much pressure to make our tool like the other guys, can actually have a negative impact. It can dim the developers vision for his product. You know the old saying "too many cooks spoil the stew". This can happen with software development.