I am using PB 9.0.3 Build 8565 on Win XP Prof. I am using PFC resizing
service. I am having issue using tabs. I am using u_tab & u_tabpg with u_dw
stuck on them. I have followed the steps as given in
http://www.pfcguide.com/faq/faq_res.asp. My first tab is a single record and
all the following tabs have the details (Master-Detail). It all seems to be
working fine but whenever my Detail tabs have rows beyond the height of the
DW no scroll bar appears. I can't figure out what is happening. I open MDI
Frame in maximized state and then open each window using OpenSheet within
this frame.
I have another application where I don't use the PFC Resize service but call
Resize in postopen of the window and make it a bit less than the
WorkSpaceHeight. In that application the scroll bar appears immediately when
the multiple rows become more than the height of the DW.
Can anybody suggest a solution.
Thanks
Amal
Yes, I have enabled the Vertical Scrollbar. I have an object u_tabpg_dw
where I have a DW control on a tab page. I have enabled it on that. I am
Resizing the TabPage first "ScaleToRight&Bottom" and then the DW. I
experimented a bit. If I disable PFC Resize on the DW control then Scroll
bar shows up. If I ScaleToBottom it resizes the height and the Scroll bar
shows up when rows exceed the DW size but if I do a ScaleToRight the scroll
bar does not show up despite the fact that DW is occupying only half of the
screen and has been stretched horizontally.
There is another issue which is bugging but of lower importance right now.
Even when
scroll bar shows up, some bottom portion of the DW is hidden behind status
bar and below.
Thanks
Amal
"Scott Morris" <bo...@bogus.com> wrote in message
news:4a043028@forums-1-dub...
You are losing me. The topic is the vertical scroll bar, is it not? Why
would changing the width cause the vertical scrollbar to appear? Are we
talking about the scrollbars WITHIN the datawindow?
>
> There is another issue which is bugging but of lower importance right now.
> Even when
> scroll bar shows up, some bottom portion of the DW is hidden behind status
> bar and below.
Focus on one problem at a time. In the future, it will help to indicate
which version and build of PB you are using as well as any additional
"extensions" you have implemented in your code and GUI. "Status bar" seems
to indicate that you have your own custom interface (within the window, the
tab control, something else - it isn't clear). Perhaps it would be easier
for you to debug if you created a simple window with a simple tab control
and verified that the issue exists without any GUI extensions other than the
resize service.
Scott, sorry if I confused you. Yes, we are talking about Vertical Scroll
bar. I am not sure what you mean by scrollbars within DW. I will try to give
you more detail. The vertical scroll bar is present on the u_dw control
which I have placed on u_tabpg. I have switched ON Vert Scrolling & Live
Scrolling in this u_dw control.
I am also a bit surprised that changing the width is making the scrollbar
disappear, i.e. ScaleToRight is affecting vertical scroll bar. I have no
clue why this is happening.
>>
>> There is another issue which is bugging but of lower importance right
>> now. Even when
>> scroll bar shows up, some bottom portion of the DW is hidden behind
>> status
>> bar and below.
>
> Focus on one problem at a time. In the future, it will help to indicate
> which version and build of PB you are using as well as any additional
> "extensions" you have implemented in your code and GUI. "Status bar"
> seems to indicate that you have your own custom interface (within the
> window, the tab control, something else - it isn't clear). Perhaps it
> would be easier for you to debug if you created a simple window with a
> simple tab control and verified that the issue exists without any GUI
> extensions other than the resize service.
I am using PFCs statusbar service on the frame window.
You are right. Lets focus on the Vertical Scroll problem right now. I will
see if I can create a new tab control and check what you suggested. I have a
class library above PFC where I have done all this so it will be a bit
cumbersome for me to make changes to it all.
Here is the main code I have written:
In wm_tab_parent's pfc_preopen:
// Turn on the Window Resize Service
THIS.of_SetResize (TRUE)
IF IsValid(inv_resize) THEN
inv_resize.of_GetMinMaxPoints(control, li_X, li_Y, li_MaxX, li_MaxY)
inv_resize.of_SetOrigSize(li_MaxX, li_MaxY)
END IF
In wm_tab_parent's ue_resize event:
IF IsValid(THIS.inv_resize) THEN
THIS.inv_resize.of_Register(itab_Parent, "ScaleToRight&Bottom")
END IF
The above is triggered in the actual transaction window inherited from
wm_tab_parent. The code is written in the pfc_preopen
itab_Parent = tab_main
Event ue_resize()
In Constructor of u_tabpg_dw:
// Turn on the Resize Service
THIS.of_SetResize (TRUE)
IF IsValid(THIS.inv_resize) THEN
THIS.inv_resize.of_Register (dw_main, "ScaleToRight&Bottom")
END IF
Hope this will help you zoom into my problem.
Thanks
Amal
As am I. Note that I am assuming you are using a current version of PB. It
is best to always include that information (version AND build) at the
beginning of every topic.
> I am using PFCs statusbar service on the frame window.
> You are right. Lets focus on the Vertical Scroll problem right now. I will
> see if I can create a new tab control and check what you suggested. I have
> a class library above PFC where I have done all this so it will be a bit
> cumbersome for me to make changes to it all.
>
> Here is the main code I have written:
>
> In wm_tab_parent's pfc_preopen:
> // Turn on the Window Resize Service
> THIS.of_SetResize (TRUE)
>
> IF IsValid(inv_resize) THEN
> inv_resize.of_GetMinMaxPoints(control, li_X, li_Y, li_MaxX, li_MaxY)
> inv_resize.of_SetOrigSize(li_MaxX, li_MaxY)
> END IF
>
> In wm_tab_parent's ue_resize event:
> IF IsValid(THIS.inv_resize) THEN
> THIS.inv_resize.of_Register(itab_Parent, "ScaleToRight&Bottom")
> END IF
>
> The above is triggered in the actual transaction window inherited from
> wm_tab_parent. The code is written in the pfc_preopen
> itab_Parent = tab_main
> Event ue_resize()
It is difficult to follow your event / function flow and how you intended
things to work. Can't really see the point of having a separate event if it
is only called once and simply does some registration - which should only
need to be done once.
>
> In Constructor of u_tabpg_dw:
> // Turn on the Resize Service
> THIS.of_SetResize (TRUE)
> IF IsValid(THIS.inv_resize) THEN
> THIS.inv_resize.of_Register (dw_main, "ScaleToRight&Bottom")
> END IF
Why are you using dw_main in the of_register function? You should be using
"this".
I mentioned in my first post that I am using PB 9.0.3 Build 8565 on Win XP
Prof.
The reason for the separate event is that this code is written in the actual
window with the tab control u_tab stuck on it (which in turn has all the tab
pages with DWs). The wm_tab_parent does not have any tab on it. It is just a
inherited window from PFC. If I understand correctly we have to create a tab
separately with all the tab pages and stick it on the window. If I write the
code in the parent, "itab_Parent = tab_main" would be invalid as there is no
tab control. So I have written it in the actual window. After initializing
the value I request initialzing the Resize service for this tab:
>> In wm_tab_parent's ue_resize event:
>> IF IsValid(THIS.inv_resize) THEN
>> THIS.inv_resize.of_Register(itab_Parent, "ScaleToRight&Bottom")
>> END IF
If this approach is incorrect pls let me know. I am trying to write as much
code in the parent as possible so that it is generic and there is no
repetition in each window.
You are right about using THIS in Constructor of u_tabpg_dw. I missed that
out. If I understand, it shouldn't be making much difference though.
Thanks
Amal
"Scott Morris" <bo...@bogus.com> wrote in message
news:4a09c63d$1@forums-1-dub...
Yes - I missed that. Keep in mind that you are still using a very old and
unsupported version. Any actual bugs with that version are quite likely to
have been fixed during the half decade that has elapsed.
> The reason for the separate event is that this code is written in the
> actual window with the tab control u_tab stuck on it (which in turn has
> all the tab pages with DWs). The wm_tab_parent does not have any tab on
> it. It is just a inherited window from PFC. If I understand correctly we
> have to create a tab separately with all the tab pages and stick it on the
> window. If I write the code in the parent, "itab_Parent = tab_main" would
> be invalid as there is no tab control. So I have written it in the actual
> window. After initializing the value I request initialzing the Resize
> service for this tab:
>
>>> In wm_tab_parent's ue_resize event:
>>> IF IsValid(THIS.inv_resize) THEN
>>> THIS.inv_resize.of_Register(itab_Parent, "ScaleToRight&Bottom")
>>> END IF
As an aside, it is odd that you check for a valid resize service object yet
don't do so for the itab_Parent object. Since you are experiencing an
issue, you should also be checking for errors everywhere - and this includes
the of_register event.
>
> If this approach is incorrect pls let me know. I am trying to write as
> much code in the parent as possible so that it is generic and there is no
> repetition in each window
Seems like you are missing the philosophy behind inheritance. The parent
should NEVER need to know anything about the child. Though it is generally
a good idea to have a corporate layer to provide standardization and support
future design changes, you don't currently seem to have a purpose for
wm_tab_parent - you could simply create your window by inheriting from
w_main (or w_sheet or any of the others). However, let us assume there is a
valid purpose for having such a parent class. In such a class, there is no
need for a instance variable itab_Parent. Its presence is only serving to
add complexity and tie the two classes together in an unhealthy manner.
In your parent class, you instantiate the resize service and register
whatever controls it contains with the service. It should do nothing with
the tab because it does not know that such a thing exists. Choose whichever
event you like to do this; pfc_preopen works just as the open event does (as
do others). In the window with the tab control, you should use the same
event, extending it by adding your registration of the tab control with the
resize service. There isn't any good reason to require the parent class to
do this; doing so tightly couples the two classes and usually makes them
unusable for any other purpose.
> You are right about using THIS in Constructor of u_tabpg_dw. I missed that
> out. If I understand, it shouldn't be making much difference though.
But it can - and cause major issues! More importantly, this is the proper
way for events and functions within a class to refer to the instantiated
object itself.
BTW - now that I look at little closer, I can see that there are two
different resize features in use. I have used the window resize service
without any issues many many times - and that has been the basis of my
comments. I have never used the datawindow resize service. Am I correct in
assuming that things work correctly without the DW resize service (ignoring
whatever it is you desire by enabling that service)? And that the issue
only appears when the DW resize service is enabled? If so, then the next
question is does the DW resize service work correctly at all with your
particular datawindow when it (the datawindow) is used directly in a window
(and not in a tab). It may be that the DW resize logic is having issues
with your datawindow design - and that's beyond my experience.
Thanks for your reply. PB 9.0.3 was a good stable version so I assume most
of the PFC stuff should work.
"Scott Morris" <bo...@bogus.com> wrote in message
news:4a0ad1df$1@forums-1-dub...
Yes, I added that check and as you said I will put in more checks.
>>
>> If this approach is incorrect pls let me know. I am trying to write as
>> much code in the parent as possible so that it is generic and there is no
>> repetition in each window
>
> Seems like you are missing the philosophy behind inheritance. The parent
> should NEVER need to know anything about the child. Though it is
> generally a good idea to have a corporate layer to provide standardization
> and support future design changes, you don't currently seem to have a
> purpose for wm_tab_parent - you could simply create your window by
> inheriting from w_main (or w_sheet or any of the others). However, let us
> assume there is a valid purpose for having such a parent class. In such a
> class, there is no need for a instance variable itab_Parent. Its presence
> is only serving to add complexity and tie the two classes together in an
> unhealthy manner.
>
> In your parent class, you instantiate the resize service and register
> whatever controls it contains with the service. It should do nothing with
> the tab because it does not know that such a thing exists. Choose
> whichever event you like to do this; pfc_preopen works just as the open
> event does (as do others). In the window with the tab control, you should
> use the same event, extending it by adding your registration of the tab
> control with the resize service. There isn't any good reason to require
> the parent class to do this; doing so tightly couples the two classes and
> usually makes them unusable for any other purpose.
>
I understand what you are saying but frankly this problem has only arisen in
tabs. There is something different about working with tabs. I had got a
reply from Terry on this forum earlier regarding the different architecture
of Tabs. Here is the relevant clip:
--
>I didn't understand why a u_tab does not allow addition of User objects (or
>tab pages) when it is placed on a window.
Again, a PB issue, but it's the same reason you can't add a control to
a user object after you've dropped it on the window. You can't change
the contents of a container while you're editing a different
container. It's aggravating, especially in the case of tabs, but
that's the way it works.
--
This issue kept me from making a clean parent which has no repetitive code
and most of it would be written in the parent. I am using a corporate layer
above the PFC. wm_tab_parent is a part of that layer and I did not give you
every detail so as to keep focused. I have objects inherited from u_dw,
u_tab, u_tabpg etc. With your approach we will have to write the following
repetitive code in every window. Although it might be the only way to keep
the hierarchy clean so I will live with it.
--
IF IsValid(THIS.inv_resize) THEN
THIS.inv_resize.of_Register(itab_Parent, "ScaleToRight&Bottom")
END IF
--
>> You are right about using THIS in Constructor of u_tabpg_dw. I missed
>> that out. If I understand, it shouldn't be making much difference though.
>
> But it can - and cause major issues! More importantly, this is the proper
> way for events and functions within a class to refer to the instantiated
> object itself.
>
Scott, I was incorrect here. The reason I can't THIS is that I am not trying
to resize u_tabpg_dw where this code is written but the DW. Sorry for that.
> BTW - now that I look at little closer, I can see that there are two
> different resize features in use. I have used the window resize service
> without any issues many many times - and that has been the basis of my
> comments. I have never used the datawindow resize service. Am I correct
> in assuming that things work correctly without the DW resize service
> (ignoring whatever it is you desire by enabling that service)? And that
> the issue only appears when the DW resize service is enabled? If so, then
> the next question is does the DW resize service work correctly at all with
> your particular datawindow when it (the datawindow) is used directly in a
> window (and not in a tab). It may be that the DW resize logic is having
> issues with your datawindow design - and that's beyond my experience.
As you understood correctly above. I am trying to resize the DW. I am not
sure how we can do without resizing the DW. Just resizing the window and tab
leaves the screen in a ugly shape. The DW occupying a part of the whole
screen. Yes, you are correct in assuming that things work fine till Tab
resize. I didn't grasp you last sentence fully. I am using a DW on a tab
page, not on a window. If you meant that I should try and check by putting
it directly on a window, that might not be of much help. My DWs are usual
Freeform or Tabular DWs. I don't know why they should have specific issues.
I have a PFC based app where I don't use u_tab & u_tabpg (my earlier version
of corporate layer), if I put my own resizing code there, it seems to work
fine.
Thanks
Amal