Technical Support- General Support Information -
|
Technical Support- General Support Information -
|
Free technical support will be offered for thirty days after you purchase one
of the PenRight! development tools. After your thirty days has expired, PenRight! offers
several technical support options: Our most popular program entitles you and two
additional in-house developers to unlimited support and access to our 800# for twelve
numbers, for a fee of $500.00. If you elect not to sign up for the unlimited support, we
offer a time materials rate of $85.00 per hour (minimum 30 minutes per call). We accept
most major credit cards.
The support center is open Monday through Friday from 7:00am to 4:00 pm (Pacific Coast
Time).
For more information, or to sign up for technical support, please call 510/249-6911.
The PenRight! BBS telephone number is: 510/683-9821. Set your communications package for N-8-1 and any baud rate up to 14.4k is supported. There are many interesting file areas on the PenRight! BBS which we encourage you to take advantage of!
Once you have logged onto the PenRight! BBS go to the PenRight! BBS Main Menu.
Select "F"ile to go to the File menu. If you know the name of the file you wish
to download, you can select the "D"ownload option to download it immediately.
The BBS will prompt you for a file name and download protocol. If the file name which is
to be downloaded is not know, or to just browse other files, select the "L"ist
option to display a list of files available in the current library. The BBS has many file
libraries to our users such as SOURCE, DEMOS, UTILS, etc. To move from library to library,
use the "S"elect file library command. The BBS will prompt for a library name or
a "?" can be entered to get a list of available libraries.
Please note: Many of the files available on the PenRight! BBS can also be found on our
Website. The PenRight! files are grouped according to the project type (i.e. general,
PenRight! for DOS, PenRight! for Windows, etc). To download one of these files, simply
click on it.
There are some data structures that are updated only after a call to FrmHandleEvent.
The state of radio buttons and check boxes, and therefore, group values fall into this
category. To get the correct value of a group, add the following to your code before
calling FrmGetGroupValue which is usually in the object handler routine that
CodeStart and PenRight! for Windows generates:
handled=FrmHandleEvent(event, error);
If the event is indeed handled, handled will receive a value of true, and the control
structure which the user depressed will be updated. The function EventLoop will
check whether handled is false, and if so, will call FrmHandleEvent. This is
why you were seeing what you previously expected. The event was handled after your check
on the group value.
To keep memory usage at an optimum level, it is recommended that infrequently used or information popup forms like help forms be freed from memory when no longer needed. There is a verb call and an API function call that will take care of this task for you. The verb FreeForm(formId) or API function FrmDisposeForm(&winHandle, &error) may be used after you leave the form, i.e. upon the winExitEvent of the form to be freed. You should keep forms that are frequently used and contain data in memory, because removing them from memory only to reload them will require that the data be set back down into the form's objects.
Yes, PenRight! (version 3.0 and greater) contains a function called FldResetField. To use this function you need to get a pointer to the field using FrmGetFieldPtr, change the FIELDTYPE data structure to reflect the new cell size and then call FldResetField to reformat the field text. You should not change a field's font, accent, or cell size without calling this function.
A navigational control, like other buttons, is activated on a single tap.
However, usres sometimes double-tap these controls, producing unwanted results if the
subsequent form has a control at the same coordinates.
A simple solution is to reposition the controls in the forms so that they do not appear at
the same overlay coordinates.
Another solution is to make sure PenRight!'s event queue is empty and to add a delay loop.
The queue holds up to ten events. You can create a loop to discard all unwanted events. In
this way, stray penDownEvents will not be processed on the subsequent form. Here is
a code excerpt to demonstrate the above theory.
...
struct time pTime;
unsigned char oldtime;
*error = 0;
switch(event->eType)
{
case winEnterEvent:
{
gettime(&ptime);
while(ptime.ti_sec - oldtime < 1)
{
EvtGetEvent(event, error);
if(event->eType == ctlEnterEvent)
continue;
else
FrmHandleEvent(event, error);
gettime(&ptime);
}
}
}
You're trying to find out if you have memory left to continue
dynamic allocation and, depending on which call you use you get a different answer. So,
how do you find out if you have enough memory during runtime? The usual approach is
to use the standard C memory management calls included in your C compiler. However, these
calls may not return an accurate amoutn of free memory. For example, the Borland C call, farcoreleft(..),
goes to the end of memory and counts bytes backwards to the first allocated block it
encounters. This may not be an accurate count of available memory because a larger block
could exist at a different location, i.e. between allocated blocks.
A better alternative when developing under PenRight! is to use the MsAvailableMemory
function call. MsAvailableMemory is a PenRight! function call that will return the
number of 16-byte paragraphs in the largest free memory block in conventional memory
during runtime. This function will check all of the conventional memory area above DOS in
order to report how much memory is available. Since the primary concern is to determine if
there is enough memory available, wihtout allowing memory fragmentation to become a
factor, MsAvailableMemroy is the best approach for your PenRight! application.
Note:When using the Microsoft C free(..) function call, heapmin(..) must
also be called. Otherwise the freed memory will not be returned to DOS and MsAvailableMemory
will not count it.
There are several ways to manage memory. These include:
Overlays are a convenient way of allowing large programs that would usually exceed conventional memory to operate in real mode DOS.
Overlays are modules of code that, during run time, share a common memory area. One module, .called the seed or base module, always resides in memory. This module contains, at a minimum, main(), as well as any other routines that are called consistently throughout the program. In PenRight!, for example, routines such as EventLoop() and CheckError() would be included in the base module, since they are called constantly throughout the application. Other modules are overlaid dynamically, as needed, into a shared portion of memory (the overlay buffer).
Using this scheme, the actual size of the program during run-time is the size of the base module plus the size of the largest overlay module. This significantly reduces memory requirements for execution of a program.
Guidelines
ExternFunc PROC FAR ; external assembly language routine
push bp ; save bp
mov bp, sp ; set up stack frame
sub sp,LocalSize ; Allocate local variables
:
:
call AnotherFunc ; Call another overlaid module
:
:
mov sp,bp ; Dispose local vairables
pop bp ; Restore BP
RET ; Return
ExternFunc ENDP
Using expanded memory for swapping
The function OvrInitEms() is prototyped in DOS.H as follows:
extern int far _OvrInitEms(unsigned emsHandle, unsigned emsFirst, unsigned
emsPages);
Parameters:
emsHandle Handle to EMS memory. If set to zero, the overlay manager searches for
the presence of expanded memory, and, if found, allocates sufficient
memory (if available) to contain all of the overlays minus the size of the overlay
buffer.
emsFirst The first usable EMS page.
emsPages Number of pages to allocate.
Return Value: 0 if expanded memory
is successfully allocated.
Example:
/* This example allocates 16 EMS pages (256 kb) for overlay swapping. */
#include
#include
int main(void)
{
if(_OvrInitEms(0,0,16))
{
printf(“Expanded memory cannot be allocated for overlay swapping”);
return 1;
}
else
return 0;
}
Using extended memory for swapping
The function OvrInitExt() is prototyped in DOS.H as follows.
extern int far _OvrInitExt(unsigned long extStart, unsigned long extLength);
Parameters:
extStart The starting address of XMS memory to use. If set to zero,
the function attempts to find the presence of extended memory. It also
attempts to determine the existence of other programs utilizing XMS memory.
If available XMS is found, the appropriate size (parameter extLength) is
allocated. If extStart is nonzero, memory will be allocated above the
starting address.
extLength The length, in bytes, of memory to allocate. If set to zero, the
maximum amount of memory needed and available will be allocated.
The maximum memory that will be allocated is the size of the overlays.
Return Value: 0 if extended memory is successfully allocated.
Example:
/* This example utilizes memory swapping of extended memory above linear address 0x200000L (2 MB)
*/
#include
#include
int main(void)
{
if(OvrInitExt(0x200000L,0))
{
printf(“Extended memory cannot be allocated for overlay swapping”);
return 1;
}
else
return 0;
}
Questions or Comments? |
 |
Email to: temple@penright.com |
 |
|Text version of this page| �Copyright 1998 PenRight! Corporation