Background Information

By default, Devguide 3.0 produced K&R C code such as this:

void my_callback(item, event) Panel_item item; Event *event; { foo_window1_objects *ip = (foo_window1_objects *) xv_get(item, XV_KEY_DATA, INSTANCE); fputs("foo: my_callback\n", stderr); /* gxv_start_connections DO NOT EDIT THIS SECTION */ xv_set(Foo_window1->button2, XV_SHOW, TRUE, NULL); /* gxv_end_connections */ }

Code Example B-1 K&R C code example

Devguide now produces ANSI C as the default version of C. This means that procedure names and prototypes have their parameters listed in the declaration. For example:

void my_callback(Panel_item item, Event *event) { foo_window1_objects *ip = (foo_window1_objects *) xv_get(item, XV_KEY_DATA, INSTANCE); fputs("foo: my_callback\n", stderr); /* gxv_start_connections DO NOT EDIT THIS SECTION */ xv_set(Foo_window1->button2, XV_SHOW, TRUE, NULL); /* gxv_end_connections */ }

Code Example B-2 ANSI C code example

Clearly, these forms are different. As a result, if your application is built with Devguide 3.0, you might experience problems merging the _stubs.c file(s). Also, if you use GXV and you did not use the -a switch parameter when you generated code, the 3.0.1 compiler will produce unexpected results when you compile your 3.0 application.

Porting Hints

The first time you use Devguide 3.0.1, generate the code and compile as you would normally. The compiler will generate errors for the callbacks that have been redefined (declared more than once).

For example, if your old _stubs.c file contains the following:

/* * THIS IS THE OLD STYLE FROM DEVGUIDE 3.0 */ void my_callback(item, event) Panel_itemitem; Event*event; { foo_window1_objects *ip = (foo_window1_objects *) xv_get(item, XV_KEY_DATA, INSTANCE); /** Some of my code here. */ fprintf(stderr, " foo 1\n"); fprintf(stderr, " foo 2\n"); fprintf(stderr, " foo 3\n"); fputs("foo: my_callback\n", stderr); /* gxv_start_connections DO NOT EDIT THIS SECTION */ /* gxv_end_connections */ }

Code Example B-3 Old-Style _stubs.c file

Running Devguide 3.0.1 on the same interface produces the following callback with the same name:

/* * THIS IS THE NEWLY GENERATED CALLBACK */ void my_callback(Panel_item item, Event *event) { foo_window1_objects *ip = (foo_window1_objects *) xv_get(item, XV_KEY_DATA, INSTANCE); fputs("foo: my_callback\n", stderr); /* gxv_start_connections DO NOT EDIT THIS SECTION */ xv_set(Foo_window1->button2, XV_SHOW, TRUE, NULL); /* gxv_end_connections */ }

Code Example B-4 New generated callback

Notice that you now have a callback with the same name, but with an argument list in the ANSI C style. Also, the code in the body of my_callback() does not contain any of the changes you may have added to the 3.0 version; that is, the code has not been merged. Because the original argument list is different from the ANSI standard, Devguide treats the body of the function as a new callback.

To fix the callback, copy the missing code from the old callback (see Code Example B-3 on page 190) into the new callback. Then, delete the old callback.

To fix the callback, copy the missing code from the old callback (see Code Example B-3 on page 190) into the new callback. Then, delete the old callback.:

/* * Notify callback function for 'button1'. */ void my_callback(Panel_item item, Event *event) { foo_window1_objects *ip = (foo_window1_objects *) xv_get(item, XV_KEY_DATA, INSTANCE); /** Some of my code here. */ fprintf(stderr, " foo 1\n"); fprintf(stderr, " foo 2\n"); fprintf(stderr, " foo 3\n"); fputs("foo: my_callback\n", stderr); /* gxv_start_connections DO NOT EDIT THIS SECTION */ xv_set(Foo_window1->button2, XV_SHOW, TRUE, NULL); /* gxv_end_connections */ }

Code Example B-5 Fixing the callback

System Calls

System calls differ in Solaris 1.x and Solaris 2.x. Consult the Solaris 2.x documentation to find out the changes that affect your application. For more information, see the Solaris 1.x to Solaris 2.x Transition Guide or one of the following:

• Solaris 2.x System Transition Guide For Users
• System Transition Guide for Application Developers - SunOS 5.x
• SunOS 5.x System Transition Guide for Administrators

If You Make a Mistake or Change Your Mind

If you make a mistake in generating your code, remember that the code generator backs up the previous _stubs.c file automatically and adds a .BAK extension to those files. For example, foo_stubs.c becomes foo_stubs.c.BAK. As a result, if you're not satisfied with your newly generated files, you can remove the new _stubs.c file and copy the backup to its original name. For example, if you're working on foo.G, you've generated code, and you don't like the results, you can remove your foo_stubs.c file and revert to the previous version as follows:

$ ls foo.G foo_stubs.c.BAK foo_ui.h foo.info foo_ui.o foo_stubs.c foo_ui.c $ rm foo_stubs.c $ cp foo_stubs.c.BAK foo_stubs.c