Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!COGSCI.BERKELEY.EDU!bryce From: bryce@COGSCI.BERKELEY.EDU.UUCP Newsgroups: comp.sys.amiga Subject: Re: GetScreenData() Message-ID: <8706020759.AA17900@cogsci.berkeley.edu> Date: Tue, 2-Jun-87 03:59:41 EDT Article-I.D.: cogsci.8706020759.AA17900 Posted: Tue Jun 2 03:59:41 1987 Date-Received: Thu, 4-Jun-87 06:13:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 120 Summary: info & minor documentation glitch for C-A in article <> hsgj@batcomputer.tn.cornell.edu (Dan Green) types: >In article <...> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >> Better yet, use the Intuition GetScreenData() function >> >I have Kickstart 1.2G1 and I looked in the Infominder stuff and there is >no mention at all of the GetScreenData() function under the Intuition >library docs. Guess what... a bug in the Infominder format ROM Kernal Manual! The function is described correctly in the autodocs.arc file on the Auto Docs disk. [ For you non-developers, all this stuff refers to the Gamma 1 release that C-A sent to developers just before the release of V1.2. Many people still run this version... ] [ The section of the ROM Kernal Manual that has the unix-like routine summaries was converted to Infominder (tm). A "read-only" demo version of that program was provided. Very nice!! ] [ Since this bug is only in the Infominder format, don't expect a formal bug report, C-A ] The function is also mentioned on page 52 of the 1.2 Enhancer software documentation. >------------- >Could anyone post or email me on what arguments GetScreenData() requires >and what structure ptr it returns? Thanks much, Certainly. C-A should not mind too much, so off I click into a CLI... grind, grind, whir, edit, upload. (Single tasking? Just say *NO!*) ------------------------------- intuition.library/GetScreenData NAME GetScreenData -- Get copy of a screen data structure. SYNOPSIS Success = GetScreenData(Buffer, Size, Type, Screen ) D0 A0 D0 D1 A1 BOOL Success; CPTR Buffer; USHORT Size; USHORT Type; struct Screen *Screen; FUNCTION This function safely copies into the caller's buffer data from a Screen structure Typically, this call will be used to find the size, title bar height, and other values for a standard screen, such as the Workbench screen. To get the data for the Workbench screen, one would call: GetScreenData(buff, sizeof(struct Screen), WBENCHSCREEN, NULL) NOTE: if the requested standard screen is not open, this function will have the effect of opening it. INPUTS Buffer = pointer to a buffer into which data can be copied Size = the size of the buffer provided, in bytes Type = the screen type, as specified in OpenWindow (WBENCHSCREEN, CUSTOMSCREEN, ...) Screen = ignored, unless type is CUSTOMSCREEN, which results only in copying 'size' bytes from 'screen' to 'buffer' RESULT TRUE if successful FALSE if standard screen of Type 'type' could not be opened. BUGS SEE ALSO OpenWindow() SUGGESTED USAGE :-) 1> If you open a custom screen, USE this function to determine the user's *favorite* settings. If a user has a workbench screen that has 64 extra pixels of width and 35 extra rows, it is a safe bet that *your* screen can be that large as well. It is desirable for custom screens to be the same size so that the page forward/back gadgets line up. (Even if the preferences overscan locations where documented, this would provide a more direct way of cloning the workbench.) 2> Some programs that open windows on the Workbench screen that obscure the title bar and prevent dragging or screen depth arrangement. GetScreenData() may be used to determine if, because of PAL or OVERSCAN or INTERLACE there is enough space to avoid hitting the title bar altogether. No matter what the height, leave at least one pixel at the top so the drag bar and front/back gadgets are still accessible (even if not visible). (GetScreenData not needed here) 3> If there is enough extra width some programs that use borderless windows to gain space may wish to reconsider. Other width-compensation features are easy, possible and desirable. 4> Sprite-using programs could realize that some of the low numbered sprites start to disappear with lots of extra overscan pixels added. (Really, this should be part of the GetSprite() function... hello V1.3) The best part of all this is the upward mobility it assures. If a 1280*800 display is is use, your software can auto-magically compensate, with very little extra effort. NOTES See the V1.2 enhancer docs, page 52. Also read the notes on the public GfxBase->NormalDisplayRows field. [For 68000 programmers, NormalDisplayRows(a6)]. This is a V1.2 ONLY function. Open Intuition with revision number 33. ------------- Ack! (NAK,EOT,SOH) |\ /| . {o O} . bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce ( " ) U BCPL? Just say *NO!*