Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Strange SCREEN behavior
Message
From
03/10/1997 10:45:52
 
 
To
03/10/1997 10:22:41
Larry Long
ProgRes (Programming Resources)
Georgia, United States
General information
Forum:
Visual FoxPro
Category:
FoxPro 2.x
Miscellaneous
Thread ID:
00052958
Message ID:
00053066
Views:
29
>>>>My office has an application in FPW 2.6a. We are using Windows 95 on a Novell network. We needed to add some comboboxes and checkboxes to some screens we have in a D_UDIAG.EXE file. This D_UDIAG.EXE is called by another
>>>>file called USMAPS.EXE. After we rebuilt the D_UDIAG.EXE, we ran our USMAPS.EXE and saw that the old screens
>>>>without the comboboxes and checkboxes showed up. So, as a test, we ran the D_UDIAG.EXE by itself. The new
>>>>screens showed up then. At this point, we rebuilt the USMAPS.EXE thinking that compiled copies of the old
>>>>screens from the D_UDIAG.EXE may have been included in it - an (excluded) reference to D_UDIAG is in our USMAPS.PJX. We still got the old screens after rerunning the rebuilt USMAPS.EXE.
>>>>
>>>>Does anyone have a clue as to what is going on? Our paths have not changed. We made sure there were no .SPX
>>>>files hanging around. Could it be a Windows 95/FPW 26a issue?
>>>>
>>>>Thanks,
>>>>
>>>>Dan Rhymes
>>>>My guess it that you have made two copies of the screens, one for USMAPS and another for D_UDIAG. Go into the USMAPS project >>and look for the screen file name, if it is in there, check the files exact path under the INFO project option. Another >>possibilty is that the copy was made and saved under a different file name. How do you refer to D_UDIAG? Do you pass program >>execution to it by doing a DO D_UDIAG, or is it a procedure file that you refer to indirectly by SET PROC TO D_UDIAG?
>>
>>Larry,
>>
>>The 2 copies idea was my guess too. But it turned out not to be the case unless our Information
>>Services Division people created a hidden drive on the network for backup purposes and mapped
>>some of our people to it. I'm not network savy so I don't know if that's possible.
>>
>>To answer your question, in our USMAPS.EXE we call our D_UDIAG.EXE like this:
>>DO (cHomeDir)+"D_UDIAG.EXE" WITH "UGRP"
>>
>>If you haven't guessed, the D_UDIAG.EXE contains dialog boxes pertaining to different subjects. From the
>>dialog boxes, the user can select different criteria - topics, option, data, map display items, etc. and
>>then is returned to the USMAPS.EXE. The parameter calls the specific subject's dialog box (or screen).
>>The code in the D_UDIAG.EXE calling the specific screen is:
>>IF SYSMETRIC(1) >= 800
>>DO (tcDialog)+"1.SPR"
>>ELSE
>>DO (tcDialog)+"2.SPR"
>>ENDIF
>You should be looking for UGRP*.* as the possible duplicates. The USMAPS project should contain no references to UGRP1 or UGRP2. Is this correct? Did you rebuild the project with the "Rebuild All" option?

Larry,

That's correct the USMAPS project contains no references to UGRP1 or UGRP2. And I did rebuild the project with the "Rebuild All" option.

One interesting thing - we rebuilt the USMAPS project with the USMAPS.PRG that is currently in production. It is picking up the new screens in the D_UDIAG.EXE. Looking at the revised version of the USMAPS.PRG (the one that picks up the old screens from a former incarnation of D_UDIAG.EXE) I can't find a difference in our pathing; i.e., SET DEFAULT TO ... or SET PATH TO ...

We use a lot of SQL-SELECTs. Is it possible that they are changing the directory paths?

Thanks,

Dan
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform