I am writing an application in 'C' that utilizes the SMG$ screen management
functions. One of the functions I am calling is SMG$READ_STRING to obtain
a string of characters from the user. The function seems to work ok, but the
user prompt always appears to start from the edge of the screen instead of the
virtual display edge. Also , at some point AFTER the function returns successfully,
the program will abort with an access violation. This can occur hundreds of lines
later in the program. If I remove the call to this function. Everything works fine. Are
calls to SMG$ asynchronous? Is this a known problem with SMG?
>the user prompt always appears to start from the edge of the screen instead of
>the virtual display edge
This suggests that READ_STRING doesn't know which virtual display to
place the prompt in. You should use one of the "SET CURSOR" functions
to position the cursor in the target display, then, when calling
READ_STRING, make sure you specify the virtual display in the call
(it's the 10th argument).
>at some point AFTER the function returns successfully,
>the program will abort with an access violation. This can occur hundreds of
>lines later in the program. If I remove the call to this function. Everything
>works fine. Are calls to SMG$ asynchronous?
SMG calls are not asynchronous. Without the details of the ACCVIO
message, I can only speculate. I'd guess that there is something wrong
with your argument list which is causing READ_STRING to corrupt memory
locations outside your declared bounds. For example, if the read buffer
is declared shorter than the maximum length you have specified.
It would not be unusual for such a memory corruption to result in an
ACCVIO "hundreds of lines" away.
I'd advise you carefully check your argument list. Make sure everything
is correct in position, data type and passing mechanism.
>Is this a known problem with SMG?
No, but it may be a "known problem" in programming in general,
*particularly* programming on C ;-) Note - NOT a compiler bug, a
programmer bug!. Consider:
void routine()
{ char astring[10];
$DESCRIPTOR(string_descr,astring)
...
stat=SMG$READ_STRING(&kbd,&string_descr,&prompt,&20,0,0,0,0,0,&display);
Now, since "astring" is allocated on the stack, just below the call
frame, if anything writes beyond the end of the array, it will
overflow into the call frame. This won't be "discovered" until you
return from the routine. If you're lucky, it will cause an ACCVIO.
Make sure everything agrees about the declarations of all data objects.
For a better guess as to what's going on, we'd need to see the exact
text of the ACCVIO and the code for the call to SMG$READ_STRING. Even
better, if you can cut your program down to a small example which
demonstrates the problem (say 50 lines maximum).
