Differences between revisions 22 and 23

DRAFT

Style Guide: Function Pages

This guide provides specific instructions for editing or adding your own content to each section of the Function pages in this wiki.

Contents

Style Guide: Function Pages

General Guidelines

Function pages should provide basic information about the SDL functions to allow users to most effectively utilize them in their projects.

Please observe the following for all function pages:

Do not post anything that you do not have permission to post publicly.
Sections should have adequate details to make them clear and useful while remaining brief wherever possible. Code Examples and Remarks may be more extensive than other sections if necessary.
Please remember to keep it accurate, simple, and easy to understand.
Do not remove, modify, or add to the markup (#pragma, etc.) above the page title.
Do not remove, modify, or add section headings unless specifically mentioned below.
In general, we prefer that you do not remove or modify existing content unless it is clearly incorrect or out of date.
Pages with red at the top are in progress and will often contain unusual content, formatting, or notes. Please do not remove or modify these. That will all be corrected/removed upon final edit.

For assistance with editing, saving, or wiki-appropriate markup see the Wiki Basics Style Guide or contact us at <ANTI SPAM wiki AT libsdl DOT org>.

Return to Table of Contents

Editing Specific Sections

Title

Do not edit the Title.

The Title section consists of the page heading and its markup:

= SDL_FunctionName =

It should match the address of the page and the function described on the page.

If you believe a change is necessary please contact us at <ANTI SPAM wiki AT libsdl DOT org>.

Return to Table of Contents

Description

The Description section immediately follows the page title and does not have it's own heading.

All function descriptions begin with:

Use this function to
followed by a clear and concise description of what the function does.

Note: Information presented in this section is meant to be limited. Extended description information for more complicated functions should be placed in the Remarks section instead.

red

Do not create a link to the Remarks section in the Description if additional information is located there.

If another API page is referenced in the description	Action: As always, be sure to hyperlink it and use () outside the link markup if it is a function.
If another API page is referenced in the description	Example: `[[SDL_FunctionName]](), [[SDL_StructureName]]`
If a parameter on that page is referenced in the description	Action: Use bold for the parameter name.
	Note: This is a very rare occurrence.
	Note: If the reference is to the parameter as a concept (ie: the window) rather than directly to the parameter itself (ie: window) do not make it bold. Please don't just make the word bold every time it occurs on the page.

Return to Table of Contents

Do not edit the Table of Contents.

The Table of Contents consists of the following markup and is generated automatically on the parsed page.

<<TableOfContents()>>

If you believe a change is necessary please contact us at <ANTI SPAM wiki AT libsdl DOT org>.

Return to Table of Contents

Syntax

The Syntax section consists of a code box that displays the basic components of the function using some specific formatting conventions. Please apply the following conventions when editing this section.

The basic format is as follows:

{{{#!highlight cpp
returnType* SDL_FunctionName(type1  parameter1,
                             type2* parameter2,
                             ...
                             typeN  parameterN)
}}}

red

All types and parameters should be vertically aligned.

Spacing for parameter types is left-aligned to the type on the first line.
Spacing for parameters is left-aligned to the longest param type so that there is only 1 space between the longest type (with any pointers) and its parameter.
Pointers (*, **) should be aligned next to the types (no space between) and should have at least one space following.

Markup: Use spaces as necessary to create the correct alignment. Within a code box spacing is fixed-width.

Note: To be omitted

All additional text that may be found in the header or elsewhere, such as extern, SDLCALL, etc.
The space between SDL_FunctionName and (.
Ending semi-colon (;)

Note: To be included

A space between returnType and SDL_FunctionName
Commas at the end of each line if there is more than 1 parameter
The colorizing markup #!highlight cpp

Note: Do not remove or alter the code box markup surrounding the function syntax. The starting and ending markup must remain on separate lines above and below the rest of the content in order to generate the code box.

If a function refers to a callback function	Action: Place any relevant info about the callback function in the Remarks section and place a link in the parameters section as described below.
	Note: Callback functions do not get their own pages.
	Example: SDL_AddEventWatch(), SDL_AddTimer()

Example:

{{{#!highlight cpp

           1 space      no space  spaces (as needed)
              |             \    |_________|
SDL_AudioSpec* SDL_LoadWAV_RW(SDL_RWops*     src,
                              int            freesrc,
                              SDL_AudioSpec* spec,     <- longest type
                              Uint8**        audio_buf,   sets alignment
                              Uint32*        audio_len)
||||||||||||||||||||||||||||||      \       |
      spaces (as needed)          no space  1 space
}}}

Return to Table of Contents

Function Parameters

The Function Parameters section provides basic information about each parameter in the function and is presented in table format.

red

If the parameter is void	Action: Delete the entire Function Parameters section, including the header.
	Example: SDL_AllocRW()

Otherwise, the basic format is as follows:

||'''parameter1'''||description||
||'''parameter2'''||description||
||'''parameterN'''||description||

The first column contains all of the parameter names, without types or pointers, in bold.
The second column contains a simple description of each parameter using some specific formatting conventions.
- red
  All descriptions begin with a lower case letter, end without a period, and are generally not complete sentences.
There are a few content-dependent conventions we have chosen for consistency across pages - see the tables below for details.

Markup: Use basic table markup and enclose each parameter name in bold markup.

Example: SDL_SetColorKey()

Content-dependent formatting: General
If more than one statement must be included in the description	Action: Separate them with a semi-colon (;)
	Note: This should be avoided whenever possible. See the next If statement in this table for more information.
	Example: SDL_PixelFormatEnumToMasks()
If a more detailed description is required to adequately explain a parameter	Action 1 : Appended the following, verbatim, to the end of the brief description `; see [[#Remarks\|Remarks]] for details`
	Action 2: Place the more detailed information in the Remarks section
	Action 3: See the next If in this table
	Example: SDL_CreateWindow()
If the Remarks section is large	Action 1: Create an anchor immediately before the additional comments you are adding to the Remarks section
	Action 2: Modify the Remarks link in the parameter description (see Action 2 above) to the following: `; see [[#anchorname\|Remarks]] for details` where `anchorname` matches the name you chose for the anchor in Action 1.
	Markup: Use `<<Anchor(anchorname)>>` to create the anchor in the Remarks section. See Anchors for details.
If there is a pointer associated with the parameter	Action: Avoid mentioning pointers unless they are critical to understanding the parameter or there is little other way to describe it (ie: void*)
If there is a pointer associated with the parameter	Example: SDL_SetColorKey()
If a pointer points to something that is filled in by the function or that has been filled in	Action: Use the phrase `filled in with` in the description
	Example: SDL_QueryTexturePixels()
If the description mentions a structure that has a page	Action 1: Use the following pattern to describe the parameter: `the/an` `[[SDL_StructureName]]` `structure to <action>` or `representing <some piece of information>`
	Action 2: Check the table below for structure-specific phrasing.
	Note: Be sure to hyperlink the structure name as shown.
	Example: SDL_UnionRect()
If the description mentions a structure that does not have a page	Action: Use the plain English term to describe the structure (ie: SDL_Window == `the window`) and omit the hyperlink.
	Note: Mention here does not necessarily indicate that a page does not exist. Please check the current wiki before selecting this option for wording, as a page may have been created since this was written.
	Example: SDL_RenderClear()
If a description must refer to any other page in the API	Action: Create a hyperlink to the page.
If a description must refer to any other page in the API	If the page is for an enumeration it is not necessary to describe it as an enumeration as above for structures.
If a description is referring to something that could be any one of a group of similar items (ie: rectangles)	Action: Begin the description with `a/an`
	Example: SDL_HasIntersection()
	Note: We realize that this is a somewhat arbitrary distinction depending upon your perspective. If you are unsure whether to use `a/an` or `the` it may be helpful to do a quick text search for other pages with the same or similar parameter and copy the format there. Ultimately, though, it's not worth losing sleep over. Just pick one.
If a description is referring to a specific item from a group (ie: a specific window)	Action: Begin the description with `the`
	Example: SDL_BlitScaled()
	Note: We realize that this is a somewhat arbitrary distinction depending upon your perspective. If you are unsure whether to use `a/an` or `the` it may be helpful to do a quick text search for other pages with the same or similar parameter and copy the format there. Ultimately, though, it's not worth losing sleep over. Just pick one.
If a parameter references another parameter on that same page	Action: Use bold for the parameter name.
	Note: This is a very rare occurrence.
	Note: If the reference is to the parameter as a concept (ie: the window) rather than directly to the parameter itself (ie: window) do not make it bold. Please don't just make the word bold every time it occurs on the page.
	Example: SDL_EnclosePoints()

Note: It would only rarely be appropriate to use the exact same description of a common parameter every time that parameter appears in the API. However, the same or very similar description can be used for many occurrences of the same parameter, enhancing consistency across pages. The following table provides a list of these commonly used descriptions.

Action: When choosing a description phrase for a parameter please check this list to see if any of these common descriptions is applicable, even if a minor modification is required.

Content-dependent formatting: Specific
If the parameter is SDL_Palette* palette	Action 1: Most often this description begins with `the [[SDL_Palette]] structure to`, followed by what to do with the palette.
	Action 2: The most common version is `the [[SDL_Palette]] structure to use`
	Example: SDL_SetSurfacePalette(), SDL_FreePalette()
	Note: Of course other phrases to describe this parameter may become necessary. A text search for "SDL_Palette* palette" should provide you with other descriptions if they arise.
If the parameter is SDL_Rect* rect(s)	Action 1 - rect: Most often this description begins with `the/an` `[[SDL_Rect]]` `structure` `representing the rectangle to`, followed by what the rectangle is for (ie: fill, draw, intersect, etc).
	Action 2 - rects: When the parameter is plural it refers to an array and will most often begin with `an array of` `[[SDL_Rect]]` `structures` `representing the rectangles to`, followed by what the rectangle is for.
	Example: SDL_FillRect(), SDL_RenderDrawRect(), SDL_IntersectRectAndLine(), SDL_RenderDrawRects()
	Note: Of course there are some other phrases to describe these parameters. A text search for "SDL_Rect* rect" should provide you with plenty of other examples of both the singular and plural parameters.
If the parameter is SDL_Renderer* renderer	Action 1: A rare exception, this description is always `the rendering context` (at least so far).
	red Please use this description for all occurrences of this parameter unless/until it appears in the API in a different context that calls for another description. A text search for "SDL_Renderer* renderer" should be used to determine if this has become the case.
	Example: SDL_RenderPresent(), SDL_RenderDrawLine(), SDL_CreateTexture()
If the parameter is SDL_Surface* surface	Action 1: Most often this description begins with `the [[SDL_Surface]] structure to`, followed by what is happening with the structure (ie: optimize, be locked, etc.).
	Action 2: The most common versions are `the [[SDL_Surface]] structure to update` (often used with Set functions) or `the [[SDL_Surface]] structure to query` (often used with Get functions).
	Action 3: Some will be best described by the following instead: `the [[SDL_Surface]] structure representing` <something>.
	Example: SDL_SetSurfaceRLE(), SDL_LockSurface(), SDL_GetClipRect(), SDL_SaveBMP_RW()
	Note: Of course there are some other phrases to describe this parameter. A text search for "SDL_Surface* surface" should provide you with plenty of other examples.
If the parameter is SDL_Texture* texture	Action 1: Most often this description begins with `the texture to`, followed by what is being done (see Action 2).
	Action 2: The most common versions are `the texture to update` (often used with Set functions) or `the texture to query` (often used with Get functions).
	Example: SDL_SetTextureAlphaMod(), SDL_QueryTexturePixels(), SDL_UnlockTexture()
	Note: Of course there are some other phrases to describe this parameter. A text search for "SDL_Texture* texture" should provide you with plenty of other examples.
If the parameter is SDL_Window* window	Action 1: Most often this description begins with `the window to`, followed by what is being done (ie: minimize, maximize, show, etc).
	Action 2: The most common versions are `the window to change` (often used with Set functions) or `the window to query` (often used with Get functions).
	Example: SDL_RestoreWindow(), SDL_SetWindowTitle(), SDL_GetWindowFlags()
	Note: Of course there are some other phrases to describe this parameter. A text search for "SDL_Window* window" should provide you with plenty of examples.

Note: Please do not use Includes in this section. It may occasionally be appropriate to copy and paste the parameters and descriptions from one function to another (perhaps with minor changes). This is the preferred method over using an Include.

Return to Table of Contents

Return Value

The Return Value section provides basic information about what, if anything, a function will return upon success or failure.

red

If the return value is void	Note: This is not the same as void! See table below for void return values.
	Action: Delete the entire Return Value section, including the header.
	Example: SDL_FreeSurface()

Otherwise, return values follow this basic format:

Returns <something> on success or <something else> on failure; call [[SDL_GetError]]() for more information.

Use the following tables to determine what to replace <something> and <something else> with in the standard statement above, and to determine whether some other action is required.

For simple replacements Action will only contain two replacement statements with the top being for success (<something>) and the bottom being for failure (<something else>).
Example: If the second column says
- Action:
  0
  a negative error code
then <something> should be replaced with the number 0 and <something else> should be replaced by the phrase a negative error code.
For complex replacements or other actions Action and/or a Note will detail what to do instead or as well.
Please check both tables.

Replacements by type
If the return value is an int (0 or <0)	Action: `0` `a negative error code`
If the return value is an int other than above or a float	Action: Replace `<something>` and `<something else>` with the applicable numbers.
If the return value is an int other than above or a float	Example: Returns 1 on success or 0 on failure.
If the return value is SDL_bool	Action: `SDL_TRUE` `SDL_FALSE`
If the return value is a pointer or NULL	Action:Replace `<something>` with an appropriate description of the pointer (usually leaving out any mention of the pointer, as in parameters) and replace `<something else>` with NULL.
	Note: See "If the return value type is a structure" below for more details.
	Example: SDL_SetVideoMode()
If the return value type is a structure	Action: The general format will approximate: `Returns an/the` `[[SDL_StructureName]]` `representing` `<what it represents>`, for success. The failure statement will depend upon what is returned on failure, if anything. See other Ifs for options.
	Note: Ideally in this case, you would search for other functions using the same return value and replicate the phrasing of others as appropriate. (Example search: "`returnValue` SDL_", where `returnValue` is replaced with the value you are interested in.)
	Example: SDL_CreateRGBSurfaceFrom()
If the return value is void*	Action:See "If the return value is a pointer or NULL" above.
	Note: In some cases it will be appropriate to mention the pointer. Ideally, look at other similar functions for guidance.
	Example: SDL_LoadFunction(), SDL_SetWindowData()
If the return value type is a Uint	Action: Replace `<something>` with a brief, appropriate description of the Uint.
	Example: SDL_MapRGBA(), SDL_WasInit()
	Note: Very rarely the Uint that is returned is a mask of enumerated values. See SDL_MasksToPixelFormatEnum() for an example of how to handle this.
If the return value type is a char or const char	Action: Replace `<something>` with a brief, appropriate description of the returned string.
If the return value type is a char or const char	Example: SDL_GetCurrentVideoDriver()
If there is no return value for failure (rare)	Action: Omit that part of the statement and omit the call to SDL_GetError().
If there is no return value for failure (rare)	Example: SDL_GetAudioDeviceStatus()
If there are more than 2 possible return values	Action: Add any additional values following the applicable rules above. Keep the primary success and primary failure values first and last, respectively, or place them in some other logical order (such as numerical).
If there are more than 2 possible return values	Example: SDL_HapticOpened()

Replacements by other criteria
If a parameter on that page is referenced in the return value	Action: Use bold for the parameter name.
	Note: This is a very rare occurrence.
	Note: If the reference is to the parameter as a concept (ie: the window) rather than directly to the parameter itself (ie: window) do not make it bold. Please don't just make the word bold every time it occurs on the page.
	Example: SDL_LoadWAV_RW(), SDL_GL_CreateContext()
If the return value mentions a structure that has a page	Action: Use the following pattern to describe the return value: Returns `the/an` `[[SDL_StructureName]]` `structure` `representing <some piece` `of information>`
	Note: Be sure to hyperlink the structure name as shown.
	Example: SDL_UnionRect()
If the return value mentions a structure that does not have a page	Action: Use the plain English term to describe the structure (ie: SDL_Window == window).
	Note: These structures may eventually have pages or other references worth linking to, in which case please follow the instructions above for linking to items with pages of their own.
If the return value must refer to any other page in the API	Action: Create a hyperlink to the page.
	If the page is for an enumeration it is not necessary to describe it as an enumeration as above for structures.

Note: It is extremely rare that an Include is appropriate in this section. If it were to occur it would only be to provide a list of possible return values that are based on an enumeration (or similar). In that case, please see the instructions for creating an Include in the Wiki Basics style guide, and the Include section of the Remarks style guide for details.

If you use an Include in this section, please email <ANTI SPAM wiki AT libsdl DOT org> telling us what page received the Include and what page was used as the source. We are keeping a list of all pages using Includes for future reference and this will help us to keep this list up to date. We appreciate your taking time for this extra step to help us keep our records accurate and useful. Thank you!

Return to Table of Contents

Code Examples

The Code Examples section is meant to contain simple, meaningful examples of how to use the function in a program.

Unlike other sections, which should rarely require editing once DRAFT is removed, this section is expected to change over time.

This is one of the few sections that is intended to grow and adjust as users discover more information about a function that would be helpful to share with other users.

For the most part the contents of the Code Examples section will be user-generated and this section will remain as-is until users input their examples.

Please see the Code Examples Style Guide for details on editing this section.

Return to Table of Contents

Remarks

The Remarks section is meant to contain additional information that did not fit in the other sections as well as comments regarding the behavior and use of the function in real-world applications.

Unlike other sections, which should rarely require editing once DRAFT is removed, this section is expected to change over time.

This is one of the few sections that is intended to grow and adjust as users discover more information about how a function behaves under different circumstances.

For the most part the contents of the Remarks section will be user-generated and this section will remain as-is until users input their comments.

Note: This is not an appropriate place to post questions, suggestions, bugs, or commentary. Please use the other communication channels available to you, especially the forums and Feedback form, for these types of remarks.

Please see the Remarks Style Guide for details on editing this section.

Return to Table of Contents

Related Functions

The Related Functions section provides a list of other functions specifically referenced by that function or otherwise closely related to it.

In general, a "Related Function" is one that is important to the use or understanding of the given function.

This list should not include:

the primary function on that page
every other function that might be considered "related"
- An argument can usually be made for a "relationship" between large numbers of functions. Using all of them would make these lists less valuable.
all functions of similar type or action
all functions of a related category
functions that are indirectly related (ie: it might be common to use them together)
functions that do not have a page in the wiki (usually because they are not public functions)

This list should include:

the opposite function in a function pair (ie: get/set, do/undo)
functions that represent close alternatives (ie: general and specific versions, singular and plural versions)
functions that are called by or otherwise very closely related to the actions of that function

Example: The other member of a Get and Set or Open and Close pair should be listed here, but all other Window or all other Create functions should not.

The basic format for the Related Functions list is:

== Related Functions ==
 .[[SDL_FunctionName]]
 .[[SDL_FunctionName]]

Note: The heading was included to more clearly illustrate the blank space before the period at the beginning of each list line. Without this markup the format will not parse correctly.

Note: Do not include the empty parentheses after the function names in this section.

If there is more than one function in the list	Action: List the functions in alphabetical order.
If there are no related functions	Action: This section may be removed entirely (including the heading) and added back at a later time if it becomes relevant.

Note: Function pages do not include a "Related Structures" or "Related Enumerations" section as some of the other page types do. If there are related structures or enumerations they are included in the body of the page as links (usually in the Remarks section). If you feel it is critical that a distinct section for one of these groups is included on a specific function page please contact us at <ANTI SPAM wiki AT libsdl DOT org> to discuss it.

Return to Table of Contents

The Footer section consists of a horizontal rule followed by two links separated by a comma.

Markup:

----
[[CategoryAPI]], [[CategoryHeader]]

where CategoryAPI is the same for every function page and CategoryHeader is function-specific with Header varying based on the header file containing the function (see below).

red

Category names do not always match the header file name. Please consult the following table for the correct name to use so the function will appear in the correct list(s).

Action 1: Do not edit the CategoryAPI link!

Action 2: The CategoryHeader link may be edited if the function has been relocated to another header (very rare) or if it still says [[CategoryHeader]] (as on a new page).

Markup: Replace CategoryHeader with the appropriate category name from the table that follows, or contact us at <ANTI SPAM wiki AT libsdl DOT org> to find out what category name to use.

Header File Containing the Function	Corresponding Category Name
SDL.h	CategoryInit
SDL_assert.h	CategoryAssertions
SDL_atomic.h	CategoryAtomic
SDL_audio.h	CategoryAudio
SDL_clipboard.h	CategoryClipboard
SDL_cpuinfo.h	CategoryCPU
SDL_endian.h	CategoryEndian
SDL_error.h	CategoryError
SDL_events.h	CategoryEvents
SDL_haptic.h	CategoryForceFeedback
SDL_hints.h	CategoryHints
SDL_joystick.h	CategoryJoystick
SDL_keyboard.h	CategoryKeyboard
SDL_keycode.h	CategoryKeyboard
SDL_loadso.h	CategorySharedObject
SDL_mouse.h	CategoryMouse
SDL_mutex.h	CategoryMutex
SDL_pixels.h	CategoryPixels
SDL_platform.h	CategoryPlatform
SDL_power.h	CategoryPower
SDL_rect.h	CategoryRect
SDL_render.h	CategoryRender
SDL_rwops.h	CategoryIO
SDL_scancode.h	CategoryKeyboard
SDL_surface.h	CategorySurface
SDL_syswm.h	CategorySWM
SDL_thread.h	CategoryThread
SDL_timer.h	CategoryTimer
SDL_version.h	CategoryVersion
SDL_video.h	CategoryVideo

Return to Table of Contents

Resources

Our goal is to create accurate, consistent, helpful, user-friendly documentation. We appreciate your efforts to make your additions fit into the existing framework and retain the same look and feel as much as possible.

If you have questions that aren't addressed here:

Search for another page that contains something similar to what you want to do and copy all the basics as much as applicable.
Check the other SDL Style Guides.
Post a question to Feedback and include a way to contact you.
Post a question to the Mailing List
Send a comment or question to <ANTI SPAM wiki AT libsdl DOT org> for clarification.

If you have suggestions for changes or additions to this document or any other portion of the wiki please don't hesitate to contact us with your thoughts. We are happy to have the participation!

Disclaimer

All content modifications are subject to review for consistency and quality. We reserve the right to remove or modify any content added to this wiki at any time. You may direct questions or concerns to <ANTI SPAM wiki AT libsdl DOT org>.

-  ⇤ ← Revision 22 as of 2011-05-11 18:44:30 → 
  Size: 34174
  Editor: SheenaSmith
  Comment: update content (in progress)
+   ← Revision 23 as of 2011-05-14 01:46:41 → ⇥
  Size: 34091
  Editor: SheenaSmith
  Comment: update content (in progress)
-Deletions are marked like this.
+Additions are marked like this.
 Line 257:
-Otherwise, return values follow one of these 2 basic formats, depending upon whether a call to [[SDL_GetError]]() is relevant:
 {{{
Returns <something> on success or <something else> on failure.
}}}
 ''or''
+Otherwise, return values follow this basic format:
-Line 266:
+Line 262:
-''Note'': Most often the 2nd, longer version is used unless the function does not have a failure state.

Use the following tables to determine what to replace `<something>` and `<something else>` with using the applicable standard statement above, and to determine when some other action is required.
+Use the following tables to determine what to replace `<something>` and `<something else>` with in the standard statement above, and to determine whether some other action is required.
-Line 271:
+Line 265:
-  . ''Action'': `0`<<BR>>`a negative error code`
+  . ''Action'':<<BR>>`0`<<BR>>`a negative error code`
-Line 273:
+Line 267:
- * For __complex replacements or other actions__ ''Action'' will detail what to do instead.
+ * For __complex replacements or other actions__ ''Action'' and/or a ''Note'' will detail what to do instead or as well.
-Line 276:
+Line 270:
-||||<bgcolor="#EDEDED">''Options by type''||
||<( 30%>''If'' the return value is __0 or <0__||''Action'': `0`<<BR>>`a negative error code`||
||<( |4 30%>''If'' the return value is __a float or other int than above__||''Action'': Replace `<something>` and `<something else>` with the applicable numbers.||
+||||<bgcolor="#EDEDED">''Replacements by type''||
||<( 30%>''If'' the return value is __an int (0 or <0)__||''Action'':<<BR>>`0`<<BR>>`a negative error code`||
||<( |2 30%>''If'' the return value is __an int other than above or a float__||''Action'': Replace `<something>` and `<something else>` with the applicable numbers.||
-Line 280:
+Line 274:
-||''Note'': Occasionally there are more than 2 possible return values.  Add any additional values as necessary, keeping the primary success and primary failure values first and last, respectively.||
||''Example'': [[SDL_HapticOpened]]()||
||<( 30%>''If'' the return value is __SDL_bool__||''Action'':`SDL_TRUE`<<BR>>`SDL_FALSE`||
+||<( 30%>''If'' the return value is __SDL_bool__||''Action'':<<BR>>`SDL_TRUE`<<BR>>`SDL_FALSE`||
-Line 297:
+Line 289:
-||<( |2 30%>''If'' there is __no return value for failure__ (rare)||''Action'': Omit that part of the statement.||
+||<( |2 30%>''If'' there is __no return value for failure__ (rare)||''Action'': Omit that part of the statement and omit the call to SDL_GetError().||
-Line 299:
+Line 291:
-||||<bgcolor="#EDEDED">''Options by other criteria''||
+||<( |2 30%>''If'' there are __more than 2__ possible return values||''Action'': Add any additional values following the applicable rules above.  Keep the primary success and primary failure values first and last, respectively, or place them in some other logical order (such as numerical).||
||''Example'': [[SDL_HapticOpened]]()||


||||<bgcolor="#EDEDED">''Replacements by other criteria''||

Wiki Navigation

Wiki Page Content

Style Guide: Function Pages

General Guidelines

Editing Specific Sections

Title

Description

Table of Contents

Syntax

Function Parameters

Return Value

Code Examples

Remarks

Related Functions

Footer

Resources

Disclaimer