Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Strange SCREEN behavior
Message
From
03/10/1997 11:00:04
Larry Long
ProgRes (Programming Resources)
Georgia, United States
 
 
To
03/10/1997 10:45:52
General information
Forum:
Visual FoxPro
Category:
FoxPro 2.x
Miscellaneous
Thread ID:
00052958
Message ID:
00053075
Views:
31
>>>>>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

1)Open the USMAPS project
2)Remove d_udiag file reference
3)Close the project
4)Reopen the project
5)Add the d_udiag.exe back to the project
6)Select the "PROJECT" menu bar tab and EXCLUDE it
7)Rebuild, selecting STANDALONE EXECUTABLE

Let me know what happens//:^)
L.A.Long
ProgRes
lalong1@charter.net
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform