hedger@inmet.inmet.com (11/09/89)
I just got off of the phone with Mark Williams tech support. No help. They say that vsf_color just calls the ROM BIOS. This is driving me crazy! Does anyone out there have any ideas ? The interesting thing is that this program works in all aspects except this vsf_color function. I am using a color monitor in medium resolution. . I have interrogated the work_out[] array created when v_opnvwrk() was issued and the bits pertaining to color are all set as I would expect. Even though the limited examples I have of this vsf_color function being used seem pretty straightforward, I get the sneaky suspicion that there is some other 'setup' stuff I need to do to the virtual workstation or the actual screen to play with the color stuff.... Oh well, again if anyone can help I would really appreciate it! ===================================================================== | | | Keith Hedger : {...!}uunet!inmet!hedger hedger@inmet.inmet.com | | " Tragedy plus time = comedy " | =====================================================================
hedger@inmet.inmet.com (11/09/89)
Got it! I am posting this in case anyone else out there gets bitten. First of all, the main problem was in fact user error. None of the docs that I had mentioned that when you are in medium resolution you can only use 4 colors (I knew that), but they also failed to mention that you can also use only the FIRST four colors. These are supposed to be 0=black,1=white,2=red, and 3=green. Not so, in fact 0=black,1=white,2=green and 3=blue. Anything else returns white. It never occurred to me to just try each color in order, big mistake it turns out. Anyway, that's the answer to this problem and I am going to call Mark Williams and let them know they have what appears to be a documentation error. ===================================================================== | | | Keith Hedger : {...!}uunet!inmet!hedger hedger@inmet.inmet.com | | " Tragedy plus time = comedy " | =====================================================================
covertr@force.UUCP (Richard E. Covert) (11/10/89)
In article <30200013@inmet>, hedger@inmet.inmet.com writes: > > Anyway, that's the answer to this problem and I am going to call > Mark Williams and let them know they have what appears to be a > documentation error. > | Keith Hedger : {...!}uunet!inmet!hedger hedger@inmet.inmet.com | I found another MWC manual error. If you lookup "form_do" you see that MWC says to pass a ZERO if the dialog box doesn't have any editable fields. Actually that MUST Be a negative one (-1) according to the Bantam book of GEM/AES programming. Has anyone else found any errors in the MWC Version 3.0 manual?? Rich Covert P.S. I found a VERY serious bug in Michtron's WERCS Resource Editor. DO NOT use the UNDESCORE CHARACTER (_) in object names. I am writing a GEM interface to a program and I kept blasting my HRD file while using WERCS. HRD is where WERCS stores its internal info about your RSC file. Anyway, once I stopped using the underscore char in my names WERCS hasn't bombed once. This hapens on a 520ST with TOS 1.0. My Mega ST with TOS 1.4 is in the shop so I can't determine if the bug is the infamous TOS 1.0 bug, or if it is in WERCS. But, just be warned about the underscore char and WERCS. Other then that, I really like WERCS. It has a test mode where you can see what you buttons return. It has a utility to convert DEGAS pics into icons. a really nice package. But, of course it is nice, it came from Europe!!! rec
towns@atari.UUCP (John Townsend) (11/11/89)
in article <30200012@inmet>, hedger@inmet.inmet.com says: > Nf-ID: #R:inmet:30200010:inmet:30200012:000:1163 > Nf-From: inmet.inmet.com!hedger Nov 8 12:49:00 1989 > > > I just got off of the phone with Mark Williams tech support. No help. > They say that vsf_color just calls the ROM BIOS. > [.. parts of message deleted..] > > Oh well, again if anyone can help I would really appreciate it! > > ===================================================================== > | | > | Keith Hedger : {...!}uunet!inmet!hedger hedger@inmet.inmet.com | > | " Tragedy plus time = comedy " | > ===================================================================== Do you have some code we can look at? In the meantime, I will see if I have some sample code somewhere... -- John Townsend ames!atari!towns Atari Corporation, Title Unknown
rjk752@uxf.cso.uiuc.edu (11/16/89)
I am a registered MWC purchaser also, and I recieved no notification. I have heard *rumors only* that there may even be an ANSI "C" version on the way. Any confirmation ? As far as apparent bugs. I typed the line setting the environmental variable TIMEZONE for the Chicago area into my profile. The example given is for Chicago, but it didn't work even though my built-in clock was set properly and I typed the example in verbatim. It was off by several hours. I even had the year set correctly. I found that if I ignored TIMEZONE in my profile, then it would work properly. I have version 3.0.5
john@stag.UUCP (John Stanley) (11/17/89)
I normaly wouldn't respond to this since Keith posted that he had the answer to his problem. Unfortunately his message indicates that he may not have the whole answer (and since the problem is partialy of his own doing) I felt obligated to try to set things straight... I appologise in advance if Keith does understand this and I'm "explaining" without being asked... (even if I am anyway... :^) [hedger@inmet.inmet.com writes...] > > Got it! I am posting this in case anyone else out there gets bitten. > First of all, the main problem was in fact user error. None of the > docs that I had mentioned that when you are in medium resolution you > can only use 4 colors (I knew that), but they also failed to mention > that you can also use only the FIRST four colors. Serious question.. Which four colors would you expect? > These are supposed to be 0=black,1=white,2=red, and 3=green. They normaly are... > Not so, in fact 0=black,1=white,2=green and 3=blue. Anything else > returns white. It never occurred to me to just try each color in > order, big mistake it turns out. > Anyway, that's the answer to this problem and I am going to call > Mark Williams and let them know they have what appears to be a > documentation error. The color numbers used by the vsf_color function only refer to the individual pallet numbers from the current color pallet, not to some absolute color code. MW should have made this clear in their manual. The "0=black,1=white,2=red, and 3=green" -are- the default colors. MW also should have made it clear in their manual that these are the "normal" colors you get from those pallet values, not absolute colors. (I'm rather suprised and disapointed in the MW phoneline support if this answer wasn't obvious to them...) If you've gone and changed the default colors (using a control panel or similar utility), then you're not going to get the colors MW listed for a normal setup... Medium rez allows 4 colors on-screen at a time. Unless you're good with interrupts and assembly language, that's the limit, period... Unless your program alters the color pallet instead of just selecting colors from the current pallet, the colors your program will show on the screen are going to be whatever default screen colors you've chosen to use for your machine... PS: If you do choose to alter the color pallet, then please take the time to read the default pallet on entry to your program and restore all of the default pallet entries on exit. (There aren't many programs that become very popular that alter the users chosen screen colors without putting them back before exiting...) --- John Stanley <dynasoft!john@stag.UUCP> Software Consultant / Dynasoft Systems
saj@chinet.chi.il.us (Stephen Jacobs) (11/17/89)
I've spoken with Mark Williams tech support a few times. One thing that came
out was that the minor version number x in MWC 3.0x indicates distribution
channel, not software differences (I'm not exactly sure, but I think 3.05
is software store, 3.06 is upgrade from version 2 and 3.09 is direct purchase
from Mark Williams Co). Other than that, their manual is full of enough
errors and omissions to choke the net repeating, but very few of them are real
show-stoppers. The solution is to let them know when you find one, and NEVER
to use only a single source for documentation on TOS (which is where most of
the mistakes are).
I strongly suspect that the effort needed to produce an ANSI compliant MWC
would be within the capabilities of the company. It's mostly a question of
whether they could make a worthwhile amount of money on it. I would almost
certainly purchase it, even as a new compiler rather than an upgrade, and
even with GNU C available. Another thousand people as crazy would probably
be a good start.
Steve J.rwa@cs.AthabascaU.CA (Ross Alexander) (11/22/89)
rjk752@uxf.cso.uiuc.edu writes: > I am a registered MWC purchaser also, and I recieved no notification. >I have heard *rumors only* that there may even be an ANSI "C" version on the >way. Any confirmation ? > As far as apparent bugs. I typed the line setting the environmental >variable TIMEZONE for the Chicago area into my profile. The example given >is for Chicago, but it didn't work even though my built-in clock was set >properly and I typed the example in verbatim. It was off by several hours. >I even had the year set correctly. I found that if I ignored TIMEZONE in >my profile, then it would work properly. > I have version 3.0.5 What's going on here is simple ;-) Chicago is 6 hours west of Greenwich. I bet it said the time was six hours early?? Try this: set your hardware clock to Greenwich Mean Time (a good source would be WWV on 5, 10, or 15 MHz, or CHU @ 7.335 and 14.670 MHz) and set the TIMEZONE variable correctly. MWC is attempting to emulate the Un*x way of setting clocks, in that all timestamps are carried internally in GMT, and adjusted _for display purposes only_ by the TZ variable. Ross