Re: Just starting problem

tmcole · ‎08-27-2003

I've decided to bite the bullet and start learning how to use dialogs. I've tried following an example, but I am receiving the following error message:

Error: There is no matching specific function for this generic function reference. [DLGSET]
retlog = DlgSet (dlg,IDC_averaging_interval,set_init)

I am clueless as to what is causing this or how to proceed. Can dialogues be used in a QuickWin application, as this is what the project was originally set up as.

Steven_L_Intel1 · ‎08-27-2003

This error message means that the arguments you have supplied to DLGSET don't match any valid combination for this routine. Check your argument declarations and make sure that each is of an appropriate type.

Yes, dialogs can be used in QuickWin.

Steve

tmcole · ‎08-27-2003

An error message only a mother could love.........

Steven_L_Intel1 · ‎08-27-2003

Well, the message is pretty good, though you need to know you're using a generic function. I suppose it would be nice if it listed the available matches so you can perhaps see easier what is wrong.

Steve

isn-removed200637 · ‎08-28-2003

I have come upon this in the past with what I see as perfectly ok usages of DLGSET. I have removed the problem by replacing the call to DLGSET sub with the relevant
specific function DLGSETINT, DLGSETCHAR, DLGSETLOG.
I am none the wiser as to what causes these occasional
rejections.

HTH

tmcole · ‎08-28-2003

Steve, it seems to me a lot simpler and more informative error would be "argument mismatch" and then have the caret underneath the mismatched argument. The other error message is a message only a compiler developer could get excited about (or understand).

kdkeefer · ‎08-28-2003

I certainly do not want to sound argumentative, but I agree with Steve that the error message is very good-it actually tells you what the underlying problem is (a generic function) and why the compiler can't deal with it (when the compiler encounters a generic function, it must replace it with one written specifically to handle the TYPE of argument used in the call). _However_, you have to know about the existence and properties of generic functions to realize this. That where my beef comes in. I've never used them, but I've read about them in a *hardcopy* manual. Since I've never used generic functions, I would never have learned anything about them from online "help" files (my motto: "online help isn't"). I can read a help file, but I can study a book, skimming through sections I don't use or really understand multiple times until the pieces start to fall into place. Usually I skim them when : a) I am actually looking for something else; b) bored; c) I think the topic might be worth learning about but requires more knowledge than I currently have. I think the learning curve for Fortran 95 is the opposite shape of most curves-it starts out fairly flat and then starts to get steep. I don't know if I will ever find out if it flattens out again :).
Congratulations on having the courage to try to use dialogs (I've never skimmed those chapters yet.)
Regards,
Keith

Steven_L_Intel1 · ‎08-28-2003

Would it make more sense if the message was something like "The argument list for this call does not match any of the specific procedures specified for the generic procedure referenced"? The only way I know of to make it clearer is to do what VAX Ada did - list the argument types and ranks specified and then those of all the possible matches.

Steve

tmcole · ‎08-29-2003

Steve, I can tell you right now that the alternative error message would have been of absolutely no use to me either. Again, the problem was that the type of the second argument was mismatched. If I had been alerted to that, I would have immediately known what to look at and how to correct it. Understanding the subtleties/nuances of what the "underlying" problem is and conveying this in the error message presupposes that the user has a complete understanding of CVF, which I doubt that anyone has. This has always been one of my pet peeves about software manuals, help files, error messages, etc. In most cases they assume that the user has the same knowledge of what is going on as the developer has, which is about as bad an assumption as you can make.

I remember when I first used Lahey FORTRAN. For the first time ever for a FORTRAN compiler, the error messages were actually written in plain english and, most amazingly, sent you to the page in the manual that discussed that part of the language that you had screwed up so you could figure out how to fix the problem. Plain, common sense that was revolutionary at the time.

Keith, I'm right there with you with regards to help files and User's Manuals. I HATE the concept of releasing documentation only in help files with hyperlinks everywhere. It makes it impossible to sit down and actually read and understand the documentation. The current state of affairs for software documentation reminds me of the old adventure computer game where you stumbled around occasionally discovering something, but more often than not you ended up at "wit's end". I played it on a VAX 10 machine, which pretty much dates me.........

Steven_L_Intel1 · ‎08-29-2003

If the routine you were calling was not generic, then you'd probably get a more detailed message. I'll see what we can do about helping better in the generic case.

Steve

Jugoslav_Dujic · ‎09-01-2003

For what it's worth, I still prefer VC++ method of error reporting (and which was used in MS FPS4.0 as well): every error message was accompanied with a unique error code, such as F2014. If the short message was not clear enough, hitting F1 on error code would lead to a longer explanation in a help page, frequently followed by a sample.

Jugoslav

kdkeefer · ‎09-02-2003

I agree with all of the suggestions. 1) a unique an specfic error code. After all the should "have a better idea" of why it decided to print an error message than the programmer (or especially a user). 2) One's computer can look up and display information about an error code much more quickly than can the programmer and get her/him back on track quickly. 3) A hardcopy description that one can study is the best means of studying the cause and effect of the error so that a programmer may avoid making the same error again. IBM provided items 1 and 3 for its mainframe compilers decades ago. (It also had a reputation to preserve as "the best of the best" and near monopoly profits with which to do it. Mr. Gates has the latter, I wish Microsoft had the former)
Keith