Feedback from DDT coders needed - a new Design approach

[Chris Boss]

I am working on a new DDT based Visual Designer which will work differently than my current commercial DDT Designer, and the Pro version of it still in development (likely to called the Studio version).

Those Designers emulate the coding style of EZGUI 4.0 Pro and is Event based.

I need some feedback from those who currently use one of my freeware DDT Designers and those who like to code manually (no designer) and other DDT users.

This new Designer will be a little less feature rich (than the Studio Designer), but will use a uniquely different approach which may be very useful to many. Read about it here: http://chrisboss.hypermart.net/ubb/F...ML/000060.html

The Designer would basically try to emulate the style of coding done by hand using no library code, to make it easier to post complete source code of an app on the forums and to share it with others. Since no library code would be used and only inline generated code would be used, there should be no problems sharing the complete app source code with others.

The code would depend upon standard Dialog procedure coding styles and PB control Callbacks (rather than event routines). It would require PB 9.0 so the entire new DDT command set could be used.

Rather than try to build a Designer which is so feature rich, that you depend upon the Designers advanced coding, this designer would use a different approach so as to benefit from open source, free (and even commercial) code of others. How ?

The Designer would be extensible using more plugins than my other designers and using its template engine more fully. The idea is to let users create their own plugins and templates to share with one another, which would add signficant code to ones apps.

I want the users to be able to post complete app source in the PB forums, as well as the code for their plugins and templates.

This is a project in work right now, but the idea is a sound one. I already have a completely working designer. All I have to do it work on the code generation engine, plugin engine and template engine to make it easily extensible.

And one more thing. It would be very low priced. Probably below $50.

Any comments ?

[Chris Boss]

This new Designer is coming along nicely and hopefully soon I will have a fully working designer which can be tested.

I have been working on the color palette code generation and the font code generation and have it nearly finished.

A few things were a bit tricky. DDT Fonts are not real font handles, but DDT font handles and there doesn't appear to be any way to define the system fonts. I generate different code for system fonts (there are six of them) and PB fonts. System fonts never need to be freed and you have use WM_SETFONT to pass them to the controls. PB fonts can use FONT NEW and CONTROL SET FONT.

This Designer works with a defined palette of 100 colors for each project. 16 colors are the DOS colors. 16 colors are pastel versions of the DOS colors. 8 are user defined per project. 4 are user selected system colors. and the other 56 are a one of thousands of color palettes that can be selected in the designer.

Here is an example of what PBMain may look like (may change before I am done):

FUNCTION PBMAIN()     ' (PROTECTED)
     LOCAL N&
     REDIM App_Color(0 TO 100) AS LONG
     DATA 0,8388608,32768,8421376,196,8388736,16512,12895428,8421504,16711680,65280,16776960,255,16711935,65535
     DATA 16777215,10790052,16752768,10551200,16777120,10526975,16752895,10551295,13948116,11842740,16768188,14483420,16777180,14474495,16768255
     DATA 14483455,15000804,4,5,15,24,12152831,1354655,4696063,13806287,1889763,12355907,7105207,14501001,7560264
     DATA 8873554,10186844,11500134,12813424,14126714,15440004,16753294,6058824,6719314,7379804,8040294,8700784,9361274,10021764,10682254
     DATA 6255432,7571282,8887132,10202982,11518832,12834682,14150532,15466382,2763379,3421319,4079259,4737199,5395139,6053079,6711019
     DATA 7368959,2766707,3427207,4087707,4748207,5408707,6069207,6729707,7390207,3432307,4092807,4753307,5413807,6074307,6734807
     DATA 7395307,8055807,7566195,8882055,10197915,11513775,12829635,14145495,15461355,16777215
     FOR N&=0 TO 99
          App_Color(N&)=VAL(READ$(N&+1))
     NEXT N&
     FOR N&=32 TO 35
          App_Color(N&)=GetSysColor(App_Color(N&))
     NEXT N&
     REDIM App_PBFont(6 TO 100) AS LONG
     REDIM App_SYSFont(0 TO 5) AS LONG
     App_SYSFont(0)=GetStockObject(%SYSTEM_FONT)
     App_SYSFont(1)=GetStockObject(%SYSTEM_FIXED_FONT)
     App_SYSFont(2)=GetStockObject(%ANSI_VAR_FONT)
     App_SYSFont(3)=GetStockObject(%ANSI_FIXED_FONT)
     App_SYSFont(4)=GetStockObject(%DEFAULT_GUI_FONT)
     App_SYSFont(5)=GetStockObject(%OEM_FIXED_FONT)
     FONT NEW "Arial", 10, 0,0,2,0 TO App_PBFont(6)
     FONT NEW "Courier New", 10, 0,0,1,0 TO App_PBFont(7)
     FONT NEW "Times New Roman", 10, 0,0,2,0 TO App_PBFont(8)
     FONT NEW "Modern", 10, 0,0,2,0 TO App_PBFont(9)
     DIALOG FONT "SYSTEM", 10
     IF Main_Initialize(VerNum&) THEN
          EZ_FORM1_Display 0
     END IF
END FUNCTION

The controls will use real PB control callback functions. Now that PB 9.0 supports wm_notify in callbacks, it should work well.

I will post updates of my progress.

[Chris Boss]

Oh, this Designer will use the Smart Parser technology, just like EZGUI 4.0 Pro and also my EZGUI Utility Dialog Designer.

The Utility Designer generates code in a style like EZGUI 4.0 Pro, so it uses the name EZGUI in the product name. This new Designer will be totally different and won't use an EZGUI style of coding, so I am thinking of using a name for the product which does use EZGUI in it, so as to differentiate from EZGUI style products.

I should note, that you should be able to read the form files generated by my freeware Dialog Designers, as well as EZGUI 4.0 Pro and the EZGUI Utility Designer.

[Paul Squires]

So this is somewhat of a PBForms clone? How would this be different than PBForms? PBForms parses code smartly between the editor and designer - adding a modifying code as needed. Am I missing something? Maybe you explained the difference in another thread that I could have overlooked.

[Barry Marks]

I'd like to suggest that you have a simpler and more conventional interface. The odd interface you used in EZ Dialog Designer was clever and nice looking but it took a lot of extra effort to remember which icon did what. I did finally learn the icons but when I didn't use them for a couple weeks I pretty much had to learn them over again. Many of them don't seem to be mnemonic in any way that I can see.

There was enough self-consistency that I suspect you did find them mnemonic, but they weren't to me.

Please don't take this as a complaint. I like the tool. But for someone who doesn't use a designer regularly, that's a weakness.

Barry

[Chris Boss]

One of the key features will be its extensibility.

The idea is to promote the development of templates, plugins, etc. to be shared among PB users. This will encourage code sharing.

Also it supports working with third party controls, like Egrid, SIGrid, GDImage visually in the Designer, not just a place holder.

I am working on some extra extensions to the designer so it can be expanded by users.

For users new to DDT, the Designer itself avoids a lot of API terminology to make it easier to use.

Rather than view this designer as a direct competitor to PB Forms, simply consider it an alternative method of coding. PB Forms has some features different than my designer, which many will simply prefer. I do not expect to tap into a large percentage of the PB Forms market. I do hope to fill a need for those who need something different than PB Forms or those who like to use multiple tools for different tasks. You would be surprised how many of my customers, who primarily use EZGUI 4.0 Pro, who also own PB Forms, FireFly and other Design tools.

Also because of its nature of not relying on any copywritten library code (like my other DDT designers) and more so on users extending the designers code base, via extensions, like templates and plugins, I am hoping it will produce (through its user base) a lot of code libraries which will benefit all PB'ers, including those who use PB Forms. This will benefit PB Forms users.

Another point is that the designer will be low cost. $50 is the max I would consider, but I may sell it for even less.

The Designer itself, though does tend to sheald users from the Windows API. Of course to code, will require some knowledge of the API, particularly knowledge of DDT. This will help new users get up to speed more quickly. As new users advance, they will likely want to try PB Forms since it will provide more access to all of the features available in the API.

Also, I want to promote the use of DDT more. PowerBasic put a lot into DDT in PB 9.0 and I want to showcase that and promote that.

It should be noted, that unlike my other Designers, this Designer will require the PB 9.0 compiler. You won't be able to even use PB 8.0 with it.

PowerBasics primary product is the PB Win compiler. They promote a variety of coding styles, all using the same compiler (PB Forms, SDK, hand coding DDT, even GUI engines). This designer should simply add to this variety.

[Chris Boss]

Barry,

No offense taken.

I want my designers to be different, rather than simply clone the interfaces of other designers. There are a number of reasons for this.

(1) EZGUI 4.0 Pro is my primary product. This is my top of line product. The DDT Designers simply emulate the EZGUI Designer, so EZGUI 4.0 Pro users can quickly use them. That is my most important market. This allows them to quickly move from a GUI engine to a purely DDT designer without much effort.

It should be noted, that all these new designers are based on the EZGUI 4.0 Pro Designer (they actually use the same code base). The EZGUI 4.0 Pro designer was designed specifically for EZGUI users, since many EZGUI features are unique to EZGUI and the designer needs to cator to the way EZGUI users think and how its runtime works.

Since I had a code Designer already created, it wasn't too difficult to modify it for use with DDT.

The Utility Dialog Designer you have, generates code similiar to EZGUI style coding, using its own Event engine.

This new DDT Designer will be a move away from the EZGUI style of coding and closer to a more pure DDT style of coding.

The front ends though remains similar in all the designers. Also the file formats are similiar and can be shared among some of them.

(2) Each programmer has a different style of coding and different preferences in the design environments they like to use. My designers cater to those who don't like the typical visual interface. For example I stay away from many features of VB like environments. While my designers are different in the UI, once learned they are actually quite easy to use and make a lot of sense (at least to some).

(3) Where my designers tend to shine is the code generation. I often get comments about how clean and readable the code is and how well the code works. What they may lack in the UI, they surely make up for in code generation.

I do have to admit, that I have been spoiled by my own EZGUI 4.0 Pro. I hate having to deal with all the API stuff, API constants and types. I find it a bit cryptic at times.
This is why the front end (designer) avoids a lot of API terminology, like Window Styles, classes, messages, etc. Let the code generator handle a lot of that, is my opinion.

[Simon Morgan]

I would support your idea of a dialog designer that produces more conventional DDT code. I bought you DDT Designer but haven't used it for any real project because the code it produces needs an inc file and is so different from what I am used to using 'raw' DDT, and so it looks as though it would be more difficult to maintain. But the actual look, feel and ease of use of your product I liked.

[Chris Boss]

Simon,

The EZGUI Utility Dialog Designer (and its pro version in development called Studio version) use a coding style similiar to EZGUI 4.0 Pro (event based) which converts messages into easier to use events. It requires library code, since a lot of what is done in the event engine is in the library. Also PB 8.0 didn't have the support for Fonts, like PB 9.0 does and code was needed to handle that.

I have decided it is best to break off my DDT designers into two different product lines:

(1) EZGUI style coding, so EZGUI 4.0 Pro users can use these designers for apps they don't want to use runtimes with.

(2) More conventional DDT style coding, using inline code (no library code), using control callbacks, etc. This designer would require PB 9.0, so would not ne able to work with earlier versions of PB. The new PB 9.0 DDT command set would finally make this possible.

Both Designer lines would look almost identical, except for the properties list and possibly some features may exist in one and not the other. The form files should be compatible as well.

While I did Beta test PB 9.0, I didn't want to attempt to add any PB 9.0 stuff to any of my designers, until PB 9.0 was officially released. Now I can move "full steam" on this new Designer.