Not my code, hired to maintain it (and fairly new to PB). Please see attachment.
Not my code, hired to maintain it (and fairly new to PB). Please see attachment.
Hi Ruth.
A screenshot of the specific window would be more helpful, as you are asking us to tell you if your diagram is correct. But simply based on your notes?
Based on object names I would guess that you have:
Now, as I said a screenshot would help as at least to distinguish what controls are used in w_update_tabs.
As your question focuses on the parent of u_tab_update there are ways to find the parent. You can edit it in source mode just to see the parent. To edit in source mode you only need to close the window(s) using that control, then locate in your pbl the control, right click on it and press “Edit Source”. Normally an editor will show up with some content like:
forward
global type u_tab_update from <…here is the parent…>
If you prefer to check it using the designer, you can find that information when editing the control in properties window:
In my example pfc_u_dw inherits from datawindow which is a standard visual control in powerbuilder.
Standard visual controls are:
Whenever in a visual control you see that it inherits from one of the objects listed above, it means that you inherit from a standard control. If you see something different then it means that your control inherits from a control where there are “custom levels” of inheritance.
Also you have window control, userobject control and tabpage control.
I won’t talk about window as it is pretty common.
Userobject is a standard control that can be used like a container of other controls. At the end you’ll need to place it or open it in a window (or open it as a tabpage). This is very useful. Tabpage control is actually some sort of userobject control that can be designed – customized directly to a tab control.
Be aware that except of visual control, we do have also non visual controls. They also can be inherited. The main difference between visual and non visual controls is that non visual controls do not have (and don't need) a designer when edited.
Andreas.
Hi.
John's answer is great. Hope you read it.
I always compare a datawindow control with webbrowser control. Webbrowser control is a host control that will receive some html / css / javascript and will have to render some content. Then it will have to process some user actions - events and do some other tasks like send a request to some server (example when the user clicks on a link).
Datawindow control is also a host control. What it will show during runtime may be defined when placing the control to a window or a userobject, using its dataibject property, or may be defined during runtime. Dataobject (or datawindow syntax) is "attached - hosted" to datawindow control and defines what should be rendered to the control when a retrieve is issued or a row is inserted (these are some of its basic functions).
Datawindow has it's non visual "brother": datastore. Datastore is the non visual control to use when you need to process some data in memory. Both objects have similar functions.
While this may seem complex at the beginning, you will soon find that it is a very powerful model. It gives you the possibility to set and modify the "content" to render in a datawindow or datastore. You can use many styles for the presentation and you can easily issue insert, update and delete commands to the database without having to write those statements. You can share data between a datastore and a datawindow or even between two controls containing dataobjects with the same sql command but a different style. You can export or import data. You can have external datawindows that are not based to a select statement... And many other.
Dataobject that is assigned to a datawindow or datastore control contains the syntax that the control should use to design the presentation of the data and in some specific cases may also contain data (this can be useful when working with external datawindows).
Finally, the syntax (dataobject to be hosted) can be created or modified at runtime. Generated syntax can be saved to a file or to a library (pbl) to be reused.
As I said all those may sound complex. You need to exercise and you will see that the basic concept isn't so hard to understand.
Andreas.
Hi, Ruth -
Welcome to PowerBuilder (PB) and to the Appeon Community!
I know it can be confusing at first, but as you've seen, there are two separate, but related entities that are informally called "DataWindows". I'll try to explain them...
The DataWindow Control (often referred to in the Q&A forum as DWC) is a visual object that is placed in Windows and in custom visual user objects (visual containers), like a command button or tab control. It has properties and methods (both functions and events).
There is also the DataWindow Data Object, often informally called simply a DataWindow or DW. It consists of a data source (typically, a SQL result set) and a visual presentation of the data provided by the data source. The presentation can be in one of many styles, such as tabular, grid, graph, free-format, n-up (newspaper-line columns), labels, treeview, rich text, etc. The object named "d_update_tabs" is a DataWindow Data Object. As you've observed, the DW Data Object does not support methods. It does contain all of the visual presentation information, including row sorting and data grouping definitions. It also contains the rules by which changes to the data is recorded in a database via Insert, Update and Delete SQL statements. DataWindow Data Objects are created and modified via the DataWindow Painter (designer).
Both the DWC and the DW are unique to PB, and they work together to provide the developer an extremely flexible and powerful data presentation and manipulation interface. A DWC is associated with a DW via the DWC's "dataobject" property, which names the DW Data Object the control is to use.
In a typical, simple data-entry scenario, a DW is assigned to a DWC either in the Window "painter" or in code. A PB Transaction object (a non-visual object that provides a connection to a database) is assigned to a DWC via the SetTransObject function in code. The DWC's Retrieve function is called to retrieve data from the database and the information is presented visually to the user via the rules contained in the DW Data Object. When the user makes changes to the data, mechanisms within the DWC keep track. When the DWC's Update function is called, SQL Insert/Update/Delete statements are automatically created and issued to the database using the update rules contained in the DW Data Object.
Of course, there is a lot more to the DWC and DW, but I hope this peels back a little of the "weirdness" and mystery. DataWindows may seem "weird" only because they are different.
The Q&A forum in the Appeon Community is here to help you, so I'm glad you found us. We have many experienced developers who volunteer their time and expertise to assist others as their availability permits. We're not consultants and this is not a Support Portal, but we'll try to help you the best we can.
Good luck and best regards, John
Hi Ruth;
Nice class diagram. Looks very straightforward to me to use & maintain.
Do you have a specific question(s) about this?
Regards ... Chris
Andreas.