triggerevent("selectionchanged") not take effect
Stephane Viau
I created a window function that SelectItem(index) for ddlb, and then
trigerevent("selectionchanged"), but triggerevent not take effect. Why? How
can I force the selectionchanged event?
--
Thanks,
Stephane Viau
Ottawa, Canada
Philip Salgannik
What is it you are after?
Maybe selectitem ( .. ) will work for you?
Stephane Viau <via...@rmoc.on.ca> wrote in message
news:Idf7E#9m#GA....@forums.sybase.com...
Ken Drendel
Whn using the powerbuilder defined events you do not need to add the "" in the
triggerevent
function. But at the end you need the ! . Remember only the non user defined
events
try this
ddlb_1.triggerevent(selectionchanged!)
On Tue, 11 May 1999 15:31:37 -0400,
in powersoft.public.powerbuilder.general
Ken Drendel
ICQ # 34027019
Bruce Armstrong [TeamPS]
want run? If so, why not move that code to a custom user event or object
level function, and then call it from both places.
On Tue, 11 May 1999 14:58:07 -0400,
in powersoft.public.powerbuilder.general
Stephane Viau <via...@rmoc.on.ca> wrote:
>I created a window function that SelectItem(index) for ddlb, and then
>trigerevent("selectionchanged"), but triggerevent not take effect. Why? How
>can I force the selectionchanged event?
>
>--
>
>Thanks,
>
>Stephane Viau
>Ottawa, Canada
>
>
Bruce Armstrong [TeamPS] | Romac/Source International
mailto:Bruce.A...@eudoramail.com | mailto:jo...@sourcela.com
| http://www.romac-source.com
Preach the gospel at all times. If necessary, use words. [Francis of Assisi]
http://www.harvest.org/text/knowgod.html
Stephane Viau
to have in its rightful place...and the reason the selectionchanged! event
is more appropriate is that it returns index as argument. How can I retrieve
the selected item index in a ddlb?
Thanks
Stephane
Bruce Armstrong [TeamPS] wrote in message ...
Bruce Armstrong [TeamPS]
isn't one of the predefined events on a control.
Why would you want the index? What you want is the text for the item selected.
On Wed, 12 May 1999 10:48:38 -0400,
---
Bruce Armstrong [TeamPS] | Romac/Source International
mailto:Bruce.A...@eudoramail.com | mailto:jo...@sourcela.com
| http://www.romac-source.com
Preach the gospel at all times. If necessary, use words. [Francis of Assisi]
http://www.kidbrothers.org http://www.fccwc.org
http://www.harvest.org/text/knowgod.html
-----------== Posted via the PFCGuide Web Newsreader ==----------
http://www.pfcguide.com/_newsgroups/group_list.asp
Brett Langston
"Bruce Armstrong [TeamPS]" wrote:
> Why would you want the index? What you want is the text for the item selected.
Not true! This has been a severe oversight in Powerbuilder IMHO. Getting the
selected index of a dropdown listbox is such a basic requirement, it is hard to
understand why a function to retrieve it has not been implemented. It is, after
all, one of the standard capabilities a Windows combo box has had since Windows
1.0., but this capability is not exposed in Powerbuilder.
One good reason to need the selected index is if you have an array of user objects
which are represented in the dropdown listbox. For instance, I might have an array
of Customer objects, each of which has a get_name() function. I want to iterate
over the array, calling Customer.get_name() for each Customer object and putting
the name in the dropdown listbox.
Now, when the user chooses one of the names from the dropdown listbox, how do I
know which Customer object the user is talking about? I certainly don't want to
get the selected text, and then search all of my Customer objects in the array to
see which one has a matching name! I simply want to get the selected index from
the dropdown listbox, and then use the result to index into the array of Customer
objects.
> FWIW, if you are calling the code from more than one place, it's rightful place
> isn't one of the predefined events on a control.
One of the reasons Stephane Viau wanted to put the code in the SelectionChanged!
event is because it is the only way to get the selected index of the dropdown
listbox. I think a better way might be to do this:
Make your own custom visual user object, inheriting from the standard dropdown
listbox control. Declare an integer instance variable to hold the currently
selected index. Put code in the selectionchanged event which saves the selected
index in the instance variable. Then, write a function called SelectedIndex which
returns the instance variable. Now, use this user object instead of the standard
dropdown listbox object in your windows. You can do this by clicking the
UserObject button in the window painter, and choosing the custom control you just
made.
Another, simpler way to get the selected index is to use this line of code:
ddlb_1.FindItem(ddlb_1.SelectedText(), 0)
There is a problem with this method, however... Since FindItem() matches any item
in the listbox that *begins* with the argument text, instead of doing an exact
match, you can sometimes get the wrong result. For instance, if you have these
items in your dropdown listbox:
Mr. Edwards
Mr. Ed
and "Mr. Ed" was the currently selected item, FindItem() would find "Mr.Edwards"
first, and therefore will not return the selected index. I think the only way to
always get the correct selected index is the custom user object method described
above.
- Brett
Philip Salgannik
have seen these problems. Datawindow is significantly smarter then a
DDLB...:-))
Brett Langston <blan...@dsi.com.mx> wrote in message
news:373B0822...@dsi.com.mx...
> Not true! This has been a severe oversight in Powerbuilder IMHO. Getting
the
> selected index of a dropdown listbox is such a basic requirement, ....
Brett Langston
listbox. However, I don't think it is too much to ask to be able to get the
selected index from a dropdown listbox.
I think many people would agree with you, when you suggest a datawindow to solve
the problem. I think this works best, however, when implementing a more
traditional solution that is diving right into the database with SQL to get its
data, and when the end result is simply to have the user select some text.
However, as in my previous example where the data is coming from, perhaps, an
array of Customer user objects, it isn't possible to implement a datawindow that
displays all of the customer names in a dropdown listbox (since the names are
encapsulated in the Customer objects). And, even if it were possible, the end
result desired is not to get the text of the customer's name, but to determine
the actual Customer object that is associated with the text.
Another consideration is the Powerbuilder-proprietary nature of a datawindow.
If I want to port my code to Java, for instance, I won't find a datawindow
object class there. I will therefore have to rewrite my code to provide the
same functionality. However, a dropdown listbox is a fairly universal concept,
implemented in every GUI on the planet. I can therefore port my code quite
easily, since I will find a corresponding dropdown listbox object in any
environment I might choose.
Lastly, using a datawindow brings in a lot of overhead, when all one wants to do
is display a dropdown listbox and figure out the index that somebody picked.
All in all, I'm not saying that using a datawindow is necessarily a bad thing,
but it is like swatting a fly with a sledgehammer sometimes. The sledgehammer
would not be necessary in some cases if only a SelectedIndex() function were
added to the dropdownlistbox class, the functionality of which is, after all,
built right into a Windows dropdown listbox anyway. It's just that Powerbuilder
won't let you access it.
Philip Salgannik
Brett Langston <blan...@dsi.com.mx> wrote in message
news:373B2413...@dsi.com.mx...
> It is very true that a datawindow is significantly smarter than a dropdown
> listbox
> However, as in my previous example where the data is coming from, perhaps,
an
> array of Customer user objects, it isn't possible to implement a
datawindow that
> displays all of the customer names in a dropdown listbox (since the names
are
> encapsulated in the Customer objects). And, even if it were possible, the
end
> result desired is not to get the text of the customer's name, but to
determine
> the actual Customer object that is associated with the text.
Why not ?
> Another consideration is the Powerbuilder-proprietary nature of a
datawindow.
> If I want to port my code to Java, for instance, I won't find a datawindow
> object class there. I will therefore have to rewrite my code to provide
the
> same functionality. However, a dropdown listbox is a fairly universal
concept,
> implemented in every GUI on the planet. I can therefore port my code
quite
> easily, since I will find a corresponding dropdown listbox object in any
> environment I might choose.
To tell you the truth I don't buy this argument :-))
Java will have it's own DDLB, Visual Basic it's own so I don't get it...
> Lastly, using a datawindow brings in a lot of overhead, when all one wants
to do
> is display a dropdown listbox and figure out the index that somebody
picked.
What overhead?. It is going to be external anyway...
Brett Langston
Philip Salgannik wrote:
> Brett Langston <blan...@dsi.com.mx> wrote in message
> news:373B2413...@dsi.com.mx...
> > It is very true that a datawindow is significantly smarter than a dropdown
> listbox
> > However, as in my previous example where the data is coming from, perhaps,
> an
> > array of Customer user objects, it isn't possible to implement a datawindow
> that
> > displays all of the customer names in a dropdown listbox (since the names
> are
> > encapsulated in the Customer objects). And, even if it were possible, the
> end
> > result desired is not to get the text of the customer's name, but to
> determine
> > the actual Customer object that is associated with the text.
>
> Why not ?
For the simple reason that a datawindow draws its info out of the database with
SQL, but the data does not reside in a database, it resides, encapsulted, in a
user object. Many people implement solutions this way, where the data is not
accessed directly from the database, but rather from some other object. This is
one of the advantages of using a three-tier architecture--it insulates the
front-end clients from direct back-end database access.
> > Another consideration is the Powerbuilder-proprietary nature of a
> datawindow.
> > If I want to port my code to Java, for instance, I won't find a datawindow
> > object class there. I will therefore have to rewrite my code to provide the
>
> > same functionality. However, a dropdown listbox is a fairly universal
> concept,
> > implemented in every GUI on the planet. I can therefore port my code quite
> > easily, since I will find a corresponding dropdown listbox object in any
> > environment I might choose.
>
> To tell you the truth I don't buy this argument :-))
> Java will have it's own DDLB, Visual Basic it's own so I don't get it...
This is simply not the case. There are only so many ways that one can implement
a dropdown listbox. Concepts like adding an item, getting the currently
selected item, etc. are universal in *all* dropdown listbox implementations,
since that is what a dropdown listbox does in *any* environment. How different
can one dropdown listbox implementation be from another?
A datawindow, however, is a proprietary Powerbuilder object. PB is the only
environment with a datawindow, so it is more difficult to port a PB datawindow
than a PB dropdown listbox. Obviously, the exact syntax needed to access the
functionality of a dropdown listbox will differ in different environments, but
all of the concepts will have a one-to-one mapping from one environment to
another, since the concepts themselves are universal. The exact concepts
embodied in a datawindow are not nearly as universal.
> > Lastly, using a datawindow brings in a lot of overhead, when all one wants
> to do
> > is display a dropdown listbox and figure out the index that somebody picked.
>
> What overhead?. It is going to be external anyway...
A datawindow is going to use more resources and be slower than just using a
dropdown listbox, if all you need to do is simply put some items in a dropdown
and get the selected index. If you use a plain ol' Windows dropdown, all of the
functionality is already provided by Windows. The only overhead incurred by,
for instance, getting the selected index from a plain dropdown listbox is one
simple SendMessage() Win32 call.
Look, it all boils down to this: A Powerbuilder programmer should be able to
choose the best way to code something, depending on the situation. If the
programmer needs a datawindow, he/she should use it. If a PB programmer has a
simpler need, such as putting a few things in a dropdown and finding out what
item was selected, he/she should be able to do that. It just doesn't make sense
to have to use a datawindow for every job. And, it doesn't make sense that
Powerbuilder will not allow me to make this choice, simply because Sybase
decided not to expose the SelectedIndex functionality that is already
implemented in every Windows dropdown listbox.
Philip Salgannik
> For the simple reason that a datawindow draws its info out of the database
with
> SQL, but the data does not reside in a database, it resides, encapsulted,
in a
> user object. Many people implement solutions this way, where the data is
not
> accessed directly from the database, but rather from some other object.
This is
> one of the advantages of using a three-tier architecture--it insulates the
> front-end clients from direct back-end database access.
This is exactly what I expected to hear :-))
This is a classic misconception. The Datawindow does not HAVE to draw
anything from the database or use SQL for that matter.
Bruce Armstrong [TeamPS]
in powersoft.public.powerbuilder.general
Brett Langston <blan...@dsi.com.mx> wrote:
>Now, when the user chooses one of the names from the dropdown listbox, how do I
>know which Customer object the user is talking about? I certainly don't want
to
>get the selected text, and then search all of my Customer objects in the array
to
from
>the dropdown listbox, and then use the result to index into the array of
Customer
>objects.
I view it from a different perspective. The issue is that the DDLB doesn't
have a code value to go with the display value, so you have to use the index
as a workaround. If you used a DDDW instead, you could put identifying info
in the code value.
>Make your own custom visual user object, inheriting from the standard dropdown
>listbox control. Declare an integer instance variable to hold the currently
>selected index. Put code in the selectionchanged event which saves the
selected
>index in the instance variable. Then, write a function called SelectedIndex
which
>returns the instance variable. Now, use this user object instead of the
standard
>dropdown listbox object in your windows. You can do this by clicking the
>UserObject button in the window painter, and choosing the custom control you
just
>made.
You could do all that, or you could simply use a datawindow. Given the choice
of writing my own control, or using a pre-written control that already provides
the functionality I need, I'll go with the latter approach.
Brett Langston
"Bruce Armstrong [TeamPS]" wrote:
> Brett Langston wrote:
> > I simply want to get the selected index from the dropdown listbox, and then
> use the
> >result to index into the array of Customer objects.
>
> I view it from a different perspective. The issue is that the DDLB doesn't
> have a code value to go with the display value, so you have to use the index
> as a workaround. If you used a DDDW instead, you could put identifying info
> in the code value.
That makes sense. Actually, that's what I would really want to do with a regular
dropdown. As it turns out, a regular dropdown does have the ability to maintain a
piece of data with each item. I'm a little rusty on my Windows API, but I think the
messages are CB_GETDATA and CB_SETDATA, or something like that.
Therefore, what I'd really like to do is have the dropdownlistbox class augmented
with a couple of functions like SetData(int index, any data) and GetData(int index)
returns any, which would merely use the pre-existing capabilites of a dropdown.
This works even if you are putting items into a sorted dropdown, since the dropdown
itself is always keeping the piece of data together with the item. Like this:
Customer cust[2]
int item
item = ddlb.AddItem(cust[1].GetName())
ddlb.SetData(item, cust[1])
item = ddlb.AddItem(cust[2].GetName())
ddlb.SetData(item, cust[2])
Now, when you want to know which Customer object the user has selected:
Customer selCust
selCust = ddlb.GetData(ddlb.SelectedIndex())
This is the same idea as using the Data property of a listviewitem or treeviewitem.
This capability is also built-in for listboxes and dropdowns, but Powerbuilder won't
let you use it. This is a shame, since it is an elegant way to implement certain
solutions.
> >Make your own custom visual user object, inheriting from the standard dropdown
> >listbox control. Declare an integer instance variable to hold the currently
> >selected index. Put code in the selectionchanged event which saves the
> selected
> >index in the instance variable. Then, write a function called SelectedIndex
> which
> >returns the instance variable. Now, use this user object instead of the
> standard
> >dropdown listbox object in your windows. You can do this by clicking the
> >UserObject button in the window painter, and choosing the custom control you
> just
> >made.
>
> You could do all that, or you could simply use a datawindow. Given the choice
> of writing my own control, or using a pre-written control that already provides
> the functionality I need, I'll go with the latter approach.
>
Point well taken. In most cases, it's better not to reinvent the wheel. I just
want to be able to use the other wheel if I want. :-)
- Brett
Brett Langston
Philip Salgannik wrote:
Good point. I need to re-examine some of the capabilities of a Datawindow.
From what you are saying, it sounds like it could be flexible enough to handle a
lot of different situations.
It is frustrating, though, to know that there are built-in capabilities of a
standard listbox or dropdown which would more than suffice for simple jobs, but
Powerbuilder won't let you access them. It's not so much a matter of saying
that a Datawindow isn't a good thing--it's one of the features that made PB
popular. I just don't like having the PB developers "edit" the capabilites of
the controls I can use, only allowing me access to the ones they deem necessary
for me to access. It is not much to ask to have pre-existing capabilites
available to the programmer, so they can make the choice as they see fit.
Thanks to everybody for all the insights, it's helpful to be able to see all of
the different points of view.
- Brett
Philip Salgannik
Brett Langston <blan...@dsi.com.mx> wrote in message
news:373C51BA...@dsi.com.mx...
> Good point. I need to re-examine some of the capabilities of a
Datawindow.
> From what you are saying, it sounds like it could be flexible enough to
handle a
> lot of different situations.
Good to know that you are beginning to see the light :-))
Now we can re-examine your considerations about Datawindow being a
proprietary technology.
You are obviously right about that. But it's not enough to say that. I will
slightly exaggerate to make a point (but I can hear them coming to tear me
apart :-)) )
Powerbuilder IS Datawindow. The rest is just nice additions. So if the
Development Tool of choice for you is PowerBuilder and you are having doubts
about using it's core technology then why use it at all?
Philip Salgannik
> However, it turns out that the object programming support in Powerbuilder
is
> very weak.
Very weak in like "but in a so-and-so RAD tool it is very strong"?
> To even change the ancestor of an object, you have to export the
> object, edit its source, and import the object.
So this is the main criticism of PowerBuilder OOP support?
What about the factual support of the main principles of OOP? Which of the
"inheritance,polymorphism and encapsulation" it does not support?
> There are no container classes
> of any kind--just arrays.
BTW Delphi 4 was proudly presenting unbounded arrays as a nice new feature
(and I can't remember since when they where present in PB)
As far as container classes and things of this nature go see my previous
statement about choosing the wrong tool :-)). But you can write them and
it's pretty easy to write in Powerscript...
> There isn't even a function like the instanceof
> operator in Java, to find out if an object is an instance of some class.
There was a whole bunch of system objects and functions added to PB6 which
allows manipulations of this sort. Take a look at ClassDefinition etc.
> In short, I was hoping to craft an elegant object-oriented solution, but
> Powerbuilder's object-oriented features don't make that possible.
In short take a harder look at Powerbuilder :-)) For some reason it was
possible for others...
> datawindows are a great feature, and they can make it easy to put together
a
> small program in a small amount of time.
The only reason you did not get a lot of responses about "small programs" is
the deceptive title of this thread :-)). People are building huge systems in
PB using it's OOP features...
> Powerbuilder is so datawindow-centric that it makes any other kind of
> programming difficult.
It is Datawindow centric because it was created as a client/server RAD tool
MAINLY for interaction with RDBMSes and not as a General programming tool.
So if we look at it in evolutionary sense then whatever has already been
done to PB by Powersoft/Sybase to make it look more like a general purpose,
object-oriented
programming tool, is really amazing...
David Broadfoot
Brett Langston <blan...@dsi.com.mx> wrote in message
news:37404BF3...@dsi.com.mx...
>
> Another good point. Datawindows are a huge part of PB, but I don't really
want
> to immerse my software with datawindow functionality, since I want to be
able to
> port it someday.
>
> My intent was to construct our software using object-oriented priciples,
not
> through the use of datawindows. My main reasons for chooing Powerbuilder,
back
> in version 5.0, is that it supported object programming through
inheritance,
> polymorphism and encapsulation. (That's what the literature said, at
> least...they were trumpeting the new object programming features of 5.0.)
C++
> was not a valid choice, since it would have taken too long for some of our
team
> members to learn. Also, another member of our small team already had some
> experience with Powerbuilder, so I thought I could leverage that. It
clearly
> seemed to be a better choice than VB, since VB's support for object
programming
> was limited at best.
>
> However, it turns out that the object programming support in Powerbuilder
is
> very weak. To even change the ancestor of an object, you have to export
the
> object, edit its source, and import the object. There are no container
classes
> of any kind--just arrays. There isn't even a function like the instanceof
> operator in Java, to find out if an object is an instance of some class.
In
> short, I was hoping to craft an elegant object-oriented solution, but
> Powerbuilder's object-oriented features don't make that possible.
>
> The thing that frustrates me is that there is no reason for this. Sure,
> datawindows are a great feature, and they can make it easy to put together
a
> small program in a small amount of time. However, I don't really think
about
> programs as sets of datawindows, and I want to be able to write the
programs
> that *I* want to write, not the programs that Sybase wants me to write.
> Powerbuilder is so datawindow-centric that it makes any other kind of
> programming difficult. And, I don't buy the argument that it is therefore
the
> wrong tool for the job--I think Sybase just neglected to fully implement
to very
> few features that would have enabled PB to be a general purpose,
object-oriented
> programming tool.