6 replies to this topic

[Rick Young]

I have a GS, that I want to call BOTH as a) as if it were a 'regular' Screen called from a menu; AND as a true GS called from within another function.

The catch: when calling it directly from a menu (or executing from ProIV command line) - it looks like a "window" not a regular screen.

Is there some way to dynamically set whether it appears like a "regular screen" or a window, depending on how its called?

Thanks
Rick

kernel v6.2.35

[Donald Miller]

Hi Rick

I've just given a quote to a customer and one of the features within it is the same global screen called as both a screen and a window. The plan is to use WinLocate to locate the Window. It states in the manual that WinLocate is not supported with MS Windows - but it works on all the MS Windows versions it's been installed in so far. Mind you it is 5.5 513.

I expect that two cycles will be required within the global screen - one set as a window and one as a screen and on entry access is to the appropriate cycle. If the screen is required from the menu then if the parameter is empty execute the screen (and if filled do the window). I've not attempted this before so I'll need to let you know how I get on. However, I do have many functions that are both Listboxes and Comboboxes. This helps to simplify maintenance.

The customer is not likely to place the order before the 4th April but I hope to have it soon after that. It is 8 weeks work but the advantage for you is that it may be able to be developed and installed as part of a stand alone module which may be completed first (in order to spread the invoicing).

If you don't hear from me - feel free to ask again. I'll mark this topic to be watched so any response should be emailed to me.

I'd do it now - but I'm chasing another (new) customer for an installation of a different (but simpler) system.

As no-one else has answered since the 11th Feb I suspect that you cannot set it to be a window or screen since for a window you need co-ordinates. However you can still use the same function (with two cycles) to help keep the maintenance under control. The development overhead is small as you develop one cycle then copy and paste and make tag name changes (if you need).

I'll post back when it's working.

Donald

[Rick Young]

Hi Donald

Thanks for the reply and for thinking outside the box a bit.

Tried your suggestion and that works fine. Even though I'm a n00b trying to drive "Developer" under V6.2 it still only took me 10-minutes to get this sorted.

I didn't use Winlocate as my current belief is that my window size/position will always be the same, no matter where I elect to call this as a window.

I just copied/pasted the entire LS/Cycle - put window co-ords on the first one, but not the other. In On Entry of the first LS, I chose to do "IF @CURFUNCT # @FUNCT THEN LSCALL("WindowScreen") LSEXIT;". From an "anticipated future maintenance" standpoint, I do agree that the additional time should be minimal - certainly less than trying to [remember to] maintain two functions.

Cheers
Rick

[Rick Young]

I should have added - this particular client is a 99.99% green screen place - so whilst I did not do any "gui-isation" at all, it does work fine under the MFC Client.

[Donald Miller]

Hi Rick

Glad you got it sorted. And glad it is possible - although mine will be GUI.

Cheers

Donald

[Lewis Mccabe]

Rick,

You can probably do it. I have not tried because we simply run the screen with a window and are done with it. We have never had a customer complain about the loss of screen real estate. The advantage is having the window title. We do it throughout our system of a couple of thousand functions. From a menu we call an update which in turn calls our global screen window function. This works fine except for a couple of issues. The title of the function does not show properly in the Windows taskbar. Secondly, if you are using an SQL database and you have a timeout turned on for the session, the timeout causes an error 366 instead of quietly returning to the menu. I am sure both of these will be an issue with your windowless approach as well

Winlocate works fine under Windows. If I remember correctly, it turns out it has always worked and the problem is with the docs. We use it extensively in 6.2

Here is how I would do what you are looking for: You need two types of parent functions - a non global screen which does a screen clear and then calls your global screen function and a global window which also calls your global non window screen function. We often use the second approach so I know it works. The user experience is not the best because the function boundaries cause the user to be unable to navigate freely to and from the global screen, but this will not be an issue in your scenario.

HTH

L:ew

[Donald Miller]

Lewis

I thought that might have been the case - need to get a more recent copy of the docs.

Thanks