order of items in control[] array of a window - powerbuilder

In the windows there is a control[] array with the controls there are in the window.
does somebody knows what is the algorithm of the order of controls in that control[] array?.
There are times that that order is changed in developmen mode and I do not why. I have a big problem with it
please help

The control array in a powerbuilder visual object container (userobject, window, etc) is maintained as controls are created and destroyed, in the internal create and destroy events. These are usually in the order in which you placed the controls on the container. So for example if we look at the source code (rightclick the object in the system tree and choose 'Edit Source', or export to a src file) of a window called 'w_my_window' where I created two commandbuttons and a datawindow:
on w_my_window.create
int iCurrent
call super::create
this.cb_1=create cb_1
this.cb_2=create cb_2
this.dw_1=create dw_1
end on
on w_my_window.destroy
call super::destroy
end on
Note that controls can be created and destroyed at other times in other events and functions if you code that way (ie dynamically creating controls using Create/OpenUserObject), and doing this will affect the control array as well.
Note also that the control array is built upon what happened in the ancestor, and descendants will continue to build on this control array.
For clarity, none of this applies to objects inside a datawindow.


How to access window variable in different .pbl with non-visual object in Powerbuilder

I have window w_1 in P1.pbl
I have non-visual object n1 in p2.pbl.
In w_1 having il_ref. I would like to access the value to n_1 object.
There are a variety of ways to accomplish your task.
You can define an instance variable of type n1 on window w_1.
n1 i_n1
You would then instantiate the variable via a create statement
i_n1 = CREATE n1
(unless the object is auto-instantiating)
Methods and variables within i_n1 are now assessable to the window (and vice versa) as long as their scope is designated PUBLIC.
Example of referencing variable on non visual from window method:
IF IsValid(i_n1) THEN
IF i_n1.il_ref > 0... //do whatever
If your non visual is already created as a global, don't make a copy on the window, just change the code above to reference the global.
In general, to have access to classes within a .PBL file, that file must be in the library list of the application. In more current versions of PowerBuilder this is maintained in the target (.PBT). There are methods to programmatically change the library list but I won't go into these here.

TObject.Show() not reachable on C++ Builder

I'm currently starting to learn how to use C++ Builder. However, I'm stuck on doing something basic, which is to open a window when I click on an element of the menu. I'm ok with the event management, but when I try to display it with the method Show(), it's written when compiling that "the method is not reachable" (I have it in french so I'm not sure about the exact translation). I've tried it different ways, also with the popup element, but I always get this message. Here is the short code that I use to display the window :
TFrame1 * NewPageFormer = new TFrame1(this);
delete NewPageFormer;
NewPageFormer = NULL;
Do you have any idea where the problem comes from?
Thank you
Try with:
TForm1 * NewPageFormer = new TForm1(this);
What you should Show() is a TForm (e.g. take a look at How do I open a new form with a button, using C++ Builder?).
Frames are combinations of components placed on a form-like object, which are considered a cohesive whole.
A frame (TFrame), like a form, is a container for other components. It uses the same ownership mechanism as forms for automatic instantiation and destruction of the components on it, and the same parent-child relationships for synchronization of component properties.
However a frame is more like a customized component than a form, so you cannot directly call the Show() method of a frame.

How to get reference of wxWidgets panel (listbox)?

I have a function in my wxWidgets application, which can be triggered by a certrain event (button push). Now I want to run in this function a method of a listbox I have in another panel, for displaying some entries etc. The listbox was instanciated in the onInit() method of the main applicationclass.
My question is, how do I get a reference to this listbox, so I can access it's printing methods?
When you created the listbox you assigned it an ID. Use that ID in a call to FindWindowById
// Construct listbox
wxListBox ( this, ID_LISTBOX );
// get pointer to listbox
wxListBox* pListBox = findwindowbyid( ID_LISTBOX )
Typically, there is a class derived from your wxWidgets form, in which you do all your work. The parent class sets up the form, and the child class then has access to all its controls, because they are members of the parent class.
In short, each of your controls should be a member variable, to which you have access.
Using wxFormBuilder (or another graphical IDE) might be helpful, because they will generate the code for you, giving you a tried and true framework in which to make your changes.

Creating Modeless Property Sheet Using Property Page Array MFC C++

I am creating a Property Sheet derived from CMFCPropertySheet it is created from the mainframe when a initial editor page is called. My question is when an additional page is called I would like a new tab created for it. Each page that is invoked will be derived by the same class but the max number of pages is unknown so it needs to be defined as
CEditorPage *m_editorpage[];
but the compiler complains that its using a zero sized array.
In the destructor I delete the pages created in a for loop from 0 to number of pages in sheet.
in post destroy I delete the this pointer.
Program crashes and stops at
delete this;
If I don't use an array it doesn't crash. But because I am using the same class page in each property page and I don't know how many there will be I need to use a zero sized array.
Either way I am getting a memory leak.
How can I create a zero sized CMFCPropertyPage based array in the Property Sheet so I can add additional pages during run time and perform proper cleanup when Property Sheet is closed. I either get a crash or memory leak in every method I have tried.
Try to use a dynamic array
CEditorPage *m_editorpage = new CEditorPage[_num_of_editorpage];
delete[] m_editorpage ;
How about using std::vector class or similar?

Adding a Gtk::Grid repeatedly to a Gtk::Box

I have a Window object which contains only a grid. I want to use Gtk::Builder to get a pointer to the grid, and then use some Gtk::Box's Gtk::Box->pack_end() to add the grid to it many times (with manipulated contents each time).
Though each time that pack_end() is called I get:
gtk_box_pack: assertion 'gtk_widget_get_parent (child) == NULL' failed in my terminal and nothing gets added to the box.
What should I do?
I want entries of a DB table to be put into a fancy widget for each record, though all the records being shown vertically one after the other. I thought I can create the fancy widget as a window in Glade and use Gtk::Builder to get a pointer to it. So in the fancy's Glade file I have a window containing a grid that has my custom appearance. I get the above error when I try to add the pointer to the fancy *grid*, to the visible window's Box. I hope I'm clear.
Here's the solution to gtk_box_pack: assertion 'gtk_widget_get_parent (child) == NULL' failed:
All that needs to be done at the first place is that you should draw the widgets WITHOUT a window, so when loaded with builder, it won't have a parent and thus the assersion succeeds.
Though here's another point: When I add the first instance of the grid to the Box, the second one results in the same error again. After a couple of trials and errors I realized that in each interation you should use Gtk::Builder::create_from_file() to create a new parent-less instance of the grid to be able to use, and this way it works.
There has to be a great difference in performance, in case number of records is gonna be big, but Gtk::Widget's copy constructor is private and direct copying is not possible, and since it wasn't my main obsession I didn't insist on resolving this "performance" issue.