Kodigo

For the next Kodigo, I have been playing around on how to name the libraries and what goes into them.

Here is my current list:

• kodigo.pb.base.pbl - contains all inherited objects from powerbuilder. Serves as an insulation layer.
  
• kodigo.core.pbl - contains core kodigo classes
• kodigo.services.pbl - contains classess implemented using SBA and are general services
• kodigo.gui.controls.pbl - contains concrete implementations of all PB controls and custom Kodigo controls
• kodigo.gui.datawindows.pbl - contains datawindow controls and specific services, including datastore services, linkage, etc.
• kodigo.gui.windows.pbl - contains window objects and specific services
• kodigo.gdiplus.pbl - contains PB implementation of GDI+

One of the goals is the ability to use a minimum set of libraries if you only want to use a subset of Kodigo. One particlar example would be the GUI part. So they would probably just need kodigo.core, kodigo.gui.controls and kodigo.gdiplus.

 What are your ideas regarding Library names and object grouping given the goal above?

I think it is a good idea to organize it such that the GUI controls can be used by people with existing applications that use PFC or other frameworks. I like the grouping but I wonder why the datawindow and window libraries have .gui. in the name? My preference would be to have only two parts in the names:

kodigo.base.pbl, kodigo.core.pbl, kodigo.services.pbl, kodigo.controls.pbl, kodigo.datawindows.pbl, kodigo.windows.pbl, kodigo.gdiplus.pbl

Hi Roland, 

Makes sense, I guess I got too caught up in the whole GUI idea. I will keep the PBL names to 2 parts, following your suggestion, thanks.

In your experience when working with PFC, for example, if you plan to use the controls in Kodigo, where would you insert it into the inheritance hierarchy? Given that kodigo.base.pbl will provide all the base inherited classes, would you:

1. Change kodigo.base.pbl inheritance from PB to PFC (e.g. inherited from nonvisualobject change to n_base)
2. Change PFC base inheritance to Kodigo
3. Do number 1 but inherit from pfc_n_base then use PFD layer that inherits from Kodigo (I'm not sure if I make sense here)

At most, I am steering away from PFC naming conventions for Kodigo to avoid any name clashes when doing integration.

Any ideas from you regarding this will help a lot. 

I don't use PFC so I don't know how it would work with controls that do not inherit from it's base objects. I wrote a framework myself back in PB5. My experience has been mostly with that. The main app at my previous employer was based on a poorly designed group of ancestor objects written in PB4.

I have been thinking about rewriting my framework so perhaps instead I can help with yours.

From reading newsgroup comments about Kodigo, I think people would be interested in it being split into two pieces. One would be the bare minimum objects to implement your GUI controls. The other piece would be an advanced framework.

On Brad's website you mentioned coming up with a new name. I think that Kodigo has gained a good amount of name recognition and should be kept.

The consensus now is to retain the name Kodigo. Due credit will be given to any ideas, design, coding, etc. for anything that will be part of the project, big or small.

Roland, any help coming from your experience I seriously consider. TopwizProgramming has been in my bookmarks since forever.

I agree with what you've mentioned. One of the goals of Kodigo is for developers to have the option of using only the control library.

Regarding PFC/3rd party integration, I will start a separate thread on that subject.

Here are the current library list names:

kodigo.base.pbl
kodigo.core.pbl
kodigo.services.pbl
kodigo.containers.pbl
kodigo.controls.pbl
kodigo.datawindows.pbl
kodigo.gdiplus.pbl

koidgo.windows has been changed to kodigo.containers, reson being that the PBL also contains userobjects that act as control hosts similar to windows. If anyone can think up of a better name, shoot.

Another thing that has been bugging me is kodigo.core and kodigo.base. The names seems to indicate that they are the same thing. kodigo.base is the immediate inheritance layer from Powerbuilder and nothing else. kodigo.core contains the ServiceManager and ServiceBase, constants/enums, global functions, etc. Is it just me or do the names "base" and "core" actually make sense?

 Hi Robo,

 Thanks for pointing that out. I have put all PB inherited objects in kodigo.base.pbl and use names not conflicting w/ PFC (pbCommandbutton, pbDatawindow, etc.) As long as we avoid name collissions w/ PFC, it should integrate well in the extension layer.

What are other issues have you encountered when integrating w/ PFC aside from name conflicts? 

Hey Yeyi, I just found the new site.  Looks great.

 Concerning the structure, I think you are on the right track.  I already did something similar to this on my version.  I basically just moved all the graphical objects and their dependencies to a pbl I could use in several different applications.  

Thanks Grismare, and welcome to the forums =) Your insight will be very helpful since you have a lot of experience with adaptation of Kodigo. So as long as we group the libraries allowing developers to pick how much of the framework they will use, and keep the object names away from common PB/PFC conventions then it should work OK.

So here is the current LibraryList:

• kodigo.base.pbl - PB inherited objects only, serves as insulation layer
  
• kodigo.core.pbl - contains utility functions, constants, service manager, service base, system services
  
• kodigo.services.pbl - non visual services (File, Bit, String, etc)
  
• kodigo.containers.pbl - contains hosts for Kodigo controls (base windows, userobjects, custom containers) I'm still thinking of merging this with the controls library.
  
• kodigo.controls.pbl - contains only visual controls, services, constants. Can be used for both vanilla PB and kodigo containers. Will also contain theme manager and control/part rendering services
• kodigo.datawindows.pbl - datawindow controls, services, constants
  
• kodigo.gdiplus.pbl - PB port of GDI+, used for kodigo.controls, etc

 
There will be another PBL for PBNI, Im still thinking if I should go this route or just use a straight DLL to open up the possibility of using Kodigo for earlier versions of PB (< v10).

I'll be posting the proposed libraries soon so you can have a feel of how the new Kodigo will work. And also to give valuable comments as well :)

PBNI started in PB9 so it depends on if you want to support versions older than that. I have PB6 thru PB11 on my home computer so I can test older versions.

I currently have PB8 and PB10 but I will stick with 10 for now until the project stabilizes. But I am considering supporting earlier versions. Someone actually ported Kodigo v3.3.1.5 to PB9 successfully. If PBNI is the only solution then Kodigo can go only up to PB9. But if I can make a DLL only version then it is possiblt to support earlier versions. I only managed to make the whole subclassing/hooking stuff to work in PBNI, I already have a couple of ideas on how to implement it as DLL only but it requires an overhaul.

I would hold off on the .dll project until after the new version is done. Then if there are enough requests to support PB8 and older you could look into it.

Agreed 

Hi,

which Kodigo version can I download/use for PB9? V3.3.1.5 requird PB10 or?

Roland Smith:

I think it is a good idea to organize it such that the GUI controls can be used by people with existing applications that use PFC 2B0-102 or other frameworks. 2B0-101 I like the grouping but I wonder why 2B0-023 the datawindow and window libraries have .gui. in the name? My preference would be to have only two parts in the names:

kodigo.base.pbl, kodigo.core.pbl, kodigo.services.pbl, kodigo.controls.pbl, kodigo.datawindows.pbl, kodigo.windows.pbl, 2B0-020 kodigo.gdiplus.pbl

 

Is everyone here sure that it is WeatherBug? I used to use it before it became heavy with addware. Even back then there was another program that was more of an infection and it had nothing to do with Weatherbug. I think the entry in Add or Remove Programs was "Weather Services" and that is what brought me here now. I have a friend's computer that is able to connect to the internet but only in safe mode. Which means that it has the ability so internet is up and running. Outside of safe mode the computer will boot and Windows will open but soon to be frozen as spyware loads in the background. This computer has "Weather Services" in Add or Remove programs but you can not remove it. Attempting to do so will cause the screen to flash sightly but other than that, nothing happens. You can do it as many times as you like and it just won't go away. This is not WeatheBug nor is it Weather Channel but some malicious program. I haven't fixed this one yet but when I do I will let you know. Unless of course, someone out there knows what i am looking for and can direct me to a place that will help.