Josh, Jarek,
I'm back, and I've isolated the problem.
To recap, I had migrated 6.0 Quick Start to only *PB*7. And then the
status bar did not work.
So next I migrated the PB6-migrated-to-PB7 Quick Start to *PFC*7. And then
the status bar worked fine (with PB7 and PFC7). So then I knew that the
fix to the status bar lay somewhere in the PFC7 code.
Using PBDelta and also searching for '7' in the PFC7 code, I found the line
that makes the PB6-migrated-to-PB7 Quick Start work... If I simply add
this line, then it works:
// In pfcwnsrv.pbl(pfc_w_statusbar)'s Open event:
// Add the following line after the this.of_SetPosition() line
dw_statusbar.InsertRow(0)
Now why would that be?
The DataObject is created dynamically, and that code was not changed. And
the same code works in 6.x. Strange. Anybody know why?
Have fun,
~Sharon
--
Sharon Weinstrom Buntz | mailto:[EMAIL PROTECTED]
Cheat Sheet for PFC/PB Help | http://www.pfccheatsheet.com/
Sharon Buntz wrote:
>
> Thanks, Jarek
>
> I tried moving that code plus of_Open() to my open event, but it still did
> not work for me. I feel so stupid <s> I'll try comparing the PFC7 Quick
> Start application to the PFC6 one later on today using PBDelta.
>
> Regarding the funny order of the events - It is probably either your
> connect to the database, your MessageBoxes, or some Yield()/of_wait() code
> related to your splash window that is allowing the queued-up posted
> pfc_postopen to execute out of its assumed turn. Pfc_postopen gets posted
> at the top of pfc_w_master's Open event. So it is raring to go whenever it
> gets a chance.
>
> Here is a list of such things that may allow queued up events to execute
> out of (assumed) turn: MessageBox(), Opening a "response"/"modal" window,
> Yield(), of_wait(), database connect, external DLL/API call, (or anything
> that would cause a wait state).
>
> Whenever debugging tricky things, remember that "You cannot observe
> something without changing its reality" <bg>... So, rather than using
> MessageBoxes or Debug mode, try using the PFC Debug/Spy service, or the
> 6.0+ Profiling Tool. In addition, you can try Title =+ 'x' tricks, or
> PBDebug=on in your [PB] section of your PB.ini file.
>
> Have fun,
> ~Sharon
> --
> Sharon Weinstrom Buntz | mailto:[EMAIL PROTECTED]
> Cheat Sheet for PFC/PB Help | http://www.pfccheatsheet.com/
>
> Jarek Mosiejewski wrote:
> >
> > Here is the the frame's open event code with the statusbar service that
> > works for me. Comparing with the PB6.5 code, I've done two things:
> >
> > - moved it form the pfc_postopen to open event,
> > - added call to of_Open function
> >
> > If IsValid (gnv_app.inv_debug) Then
> > gnv_app.inv_debug.inv_sqlspy.Post of_OpenSQLSpy (True)
> > End If
> >
> > If SQLCA.of_IsConnected () Then
> > gnv_app.Dynamic of_SetFrame (This)
> > If gnv_app.of_LogonDlg () <> Success Then
> > .
> > .
> > .
> > End If
> > End If
> >
> > This.of_SetStatusBar (True)
> > This.inv_statusbar.of_SetMem (True)
> > This.inv_statusbar.of_Open (True)
> >
> > It appears to me that it is necessary to have the inv_statusbar.of_Open call
> > as without it the service does not work (at least in my application).
> > Please note that call to inv_statusbar.of_Open is precoded in the
> > pfc_postopen event in the pfc layer.
> >
> > I've mede a very simple test by placing messagebox statements on the top of
> > the following frame's events pfc_preopen, open and pfc_postopen. They got
> > executed in the following order:
> > - pfc_preopen,
> > - pfc_postopen
> > - open
> >
> > I think this provides a clue why call to of_Open is necesery.
> >
> > Regards
> >
> > Jarek
Sharon Buntz wrote:
>
> Jarek,
>
> Are you referring to the frame's code? If so, I tried several different
> combinations of moving all code to/from open/pfc_postopen events, even
> experimenting with adding inv_statusbar.of_Open(True) in between the code,
> commenting out the splash window, etc. But I still cannot make my
> QuickStart6.0-migrated-to-7.0 status bar work.
>
> Any more clues or suggestions?
>
> Thanks,
> ~Sharon
> --
> Sharon Weinstrom Buntz | mailto:[EMAIL PROTECTED]
> Cheat Sheet for PFC/PB Help | http://www.pfccheatsheet.com/
>
> Jarek Mosiejewski wrote:
> >
> > Hi,
> >
> > I had the same problem. I got it fixed by moving code related to the status
> > bars service from the pfc_postopen event to... if I remember correcty, the
> > open event. It appers to me that the whole thing has something to do with
> > timing of events. In this particular case (I've checked it), the
> > pfc_postopen event actually executed before the code in the open event where
> > logic related to status bar used to reside.
> >
> > I hope this will help to put you on the right track
> >
> > Regards
> >
> > Jarek
> > ----- Original Message -----
> > From: Sharon Buntz <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Thursday, November 18, 1999 8:25 AM
> > Subject: Re: PFCSIG PFC status bar service
> >
> > > Josh,
> > >
> > > I would have suspected that it has to do with the fact that the
> > > istr_dwobject os_dwobjects structure is now obsolete...
> > >
> > > Object: Obsolete Structure: Replacement Class:
> > > ------- ------------ ------------------
> > > pfc_n_cst_winsrv_statusbar os_dwobjects pfc_n_cst_winsrv_statusbarattrib
> > >
> > > ...if you were using PFC 7.0, but you said you were not.
> > >
> > > So then I thought, well, maybe it has to do with the REASON that PFC
> > > obsoleted the structure in the first place. In other words, remember that
> > > 6.0 warning message,
> > > "Warning C0190: Instance variables of local structure type
> > > ('<local_structure>') will be implicitly private in the next release."
> > > Maybe they really meant what they said <g> But when I migrated my 6.0 app
> > > to 7.0, I still got only a WARNING, and it seems that there would be more
> > > problems if that were the case. (BTW, in that same PowerTimes article
> > that
> > > I quoted before, Boris explains in detail all about this as well and what
> > > PFC did to remedy it. I can send you the excerpt if you want. Or maybe
> > > he'll post it at the pfcguide.)
> > >
> > > Since that did not seem to be the problem either, I got curious and
> > > migrated 6.0 QuickStart to 7.0.1, and voila, the user id did NOT show up
> > in
> > > the status bar. Same boat as you. I couldn't figure out the exact source
> > > of the problem (I got totally lost in all the code), but I suspect that it
> > > was all fixed in PFC 7.0... Sooo...
> > >
> > > Try copying over the PFC 7.0 statusbar object, the statusbar service and
> > > the new statusbar attribute object. I bet it will work with the new PFC
> > > 7.0 code. If you get stuck, send me the exported PFC code for those
> > > objects and I'll try to help more. I don't have PFC 7.0 :-(
> > >
> > > Let us know what works out for you! Seems like such an simple innocent
> > > problem. Also seems like someone else MUST have encountered this and
> > > figured it out by now!?!? <g>
> > >
> > > Have fun,
> > > ~Sharon
> > > --
> > > Sharon Weinstrom Buntz | mailto:[EMAIL PROTECTED]
> > > Cheat Sheet for PFC/PB Help | http://www.pfccheatsheet.com/
> > >
> > >
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > > Hi Sharon:
> > > > The user id, date which I have defined dont appear on the status
> > bar..
> > > > There are also some application specific infor like the users group
> > whichalso
> > > > has been defined to appear on the status bar. The same code still works
> > in Pb
> > > > 6.5
> > > >
> > > > Thaks for the migration information..
> > > >
> > > > Thanks
> > > > Josh
> [EMAIL PROTECTED] HOSTED BY IIGG, INC. FOR HELP WITH LIST SERVE COMMANDS, ADDRESS
> A MESSAGE TO [EMAIL PROTECTED] WITH THE FOLLOWING MESSAGE: help pfcsig
> SEND ALL OTHER INQUIRES TO [EMAIL PROTECTED]
