So I had a nice long post all typed out about a pet peeve of mine: people assuming that because something doesn't work the way they want, that it's a bug. Then I decided it was too harsh to post. So I'm just going to point out some common misconceptions and hope that people read it and understand it (but I have very little hope, honestly -- this stuff has been pointed out before).
1) REALbasic uses cooperative threads. That means they're not preemptive. This is by design because cooperative threads are just plain easier for most people to use.
2) Serial and socket controls are asynchronous by nature, which means that they get a DataAvailable event when *new* data arrives. They keyword is new. That means that when any data comes in, you get a DA event -- not when "all" data comes in. These controls know nothing about your protocols. Another one that people tend to forget as well is that data can come in while you're processing in the DA event. If you are in the DA event, then it's assumed that you're processing all of the data. So another DA event isn't going to fire until you've left the original DA event and *then* new data arrives.
3) Network interfaces are designed to only be in the list for interfaces which the OS thinks you can legally use (with the exception of the loopback interface). That means NICs which aren't up and running typically aren't reported to you (though some OSes have a strange phenomenon where it will report a NIC which can't be used anyways).
4) REALbasic is cross platform *NATIVE*. That means you get native controls (generally speaking) and native functionality. That does not mean you get identical controls and identical functionality. You get reasonably identical controls and functionality, but nativeness is more important than identicalness.
There are tons of other things that I could put down here, but these are ones I seem to come across on a weekly basis (or so it seems). Just remember, the next time you think "omg! this is a bug!", take a big step back and look at a few factors. 1) Are you misunderstanding the design or use of the feature? 2) Are you certain you're using the feature properly? 3) Are you positive that when you do everything properly, you still get the wrong results? If you do all of this and there's still a problem, then please do report the issue and be *certain* to attach a project to your report that demonstrates the issue.
Ok, I think this is a bit better than the entry I deleted. Maybe. ;-)
With the controls, as things are different sizes, it might be nice to make it so that you can see what a window *might* look like on other platforms. At least so that you can align stuff up right. You get something similar with menus.
Network interfaces are designed to only be in the list for interfaces which the OS thinks you can legally use
It would be nice to get them all, anyway. I use the MAC address for copy protection, and when the user switches from hard-wired ethernet to WiFi (or vice versa), I can't check all the NIC's MAC addresses to see if one of them matches.
@Mike -- the thing to take away from this isn't that feature requests are a bad idea. :-) It's to understand that you shouldn't throw the term "bug" around too quickly without first understanding the design (not saying that you've ever done this). If you simply claim "Foo is a bug" in a report, it's very likely to just be closed as "Not a Bug" which basically wastes everyone's time. But if you file it as a feature request instead, then it won't get closed by QA (generally speaking).
It seems to me that the only real difference between a bug and a feaure request is whether the behaviour is intentional or not. And since we generally can't know what the RS engineer's intention was, we can't really be sure whether a desired change in behaviour should be classified as a bug or a feature request.
But why should it mater?
I realize that it's important for RS to classify things as a bug vs a FR, but you really shouldn't care whether a user classifies it either way. It's simply something they wish to behave differently.
The #2 post is what I'm having trouble with right now.
Maybe I was part of the um..."inspiration"...from the NUG for that one :)
If you have a few minutes to spare...
I've been trying to figure out the best way to process the data coming into the DataAvailable event. Should it just be parsed into a giant string, and dealt with later; or more of a process whatever you get when you get it type of thing? (Which approach would probably depend on the type of data being expected) - but in general, was trying to find the most efficient way of doing this when the data coming in isn't of a pre-set length (so I can't really use, eg. read(14).
If I have a timer using lookahead, that keeps running looking for no new info coming in, at say even 4000ms, it sometimes cuts off the end of where it should (maybe the data stream slowed down for a few seconds, or ?), but eitherway, it doesn't feel too reliable. Am I going about this the wrong way?
Maybe I need your RBLibrary book on serial stuff?
Hmm...Thanks again.
Joe: Sounds like you'd be happier if RB engineers added more notes and information in the Language (and Libraries) reference. I sure would have appreciated more documentation when a documented error case exception wasn't thrown on windows as it was on mac. http://tinyurl.com/2zdjee (*Documentation* Bug #: sndjoakz ) Yes the functionality of RB on Windows is different than other language libraries on windows. Bug or feature? Probably a 'feature', yet certainly a bug in documentation.
I would be ecstatic if they embedded FAQs and these recurring threads into docs. I'm sure it happens sometimes, but it has to feel like it really has impact to get any momentum, and when the question recurs, it feels like no one RTFD's.
How would they get that feeling?
Publish the language reference on-line and respond fast and often to the list postings with the URL to the answer. The rest of use could use external social annotation tools to add our own information.
Every time you pull your punches, the post is slightly less entertaining than it could be. Can you work on that, ok?
@Chad -- the standard design for processing DA events can be seen here:
http://forums.realsoftware.com/viewtopic.php?t=4601
The basic idea is to let RB do the buffering for you. So your code will look like this:
Sub DataAvailable() do // Attempt to process some data dim count as Integer = ProcessPacket( me.LookAhead ) // If we have a full packet, then count will be > 0 if count > 0 then // Remove the data from the RB internal buffer call me.Read( count ) else // We didn't process an entire packet, so we want // to bail out exit end if loop until me.BytesAvailable <= 0 End SubI would avoid using the timer since there's no need for it -- you're *told* when some data's there, so process it as you're told about it.Hmm...many thanks. That's not at all how I was going about it - that really helps. That forum thread also shows a lot, I hadn't seen that one before. Thanks again for the the direct tech support, I really appreciate it!
@jdiwnab
I miss that too sometimes... Is there a feature request where I can sign on?
Arne
Anonymous was me. Damn cookies.
Oops……I think I might be one of those people you are annoyed with for suggesting something might be a bug (re. serial port baud change). I do apologise and will make much more effort in the future to find answers to problems before making silly posts. The support on the forum is totally amazing and I’m embarrassed to think I may have abused it (even in a small way)! You’ll also be glad to know I’m reading ‘The object-Oriented Thought Process’ by Matt Weisefeld (which I should have done right at the start) so hopefully I won’t be asking any more dumb questions about OOP either.
I would also like to take this opportunity to thank you for all the help you have given me over the last few months. You really have played a big part in my enjoyment of learning RealBasic.
@Ben -- no, you're not annoying me, I promise. This was more of a general thing and meant at no one in particular. Honest!
And I'm glad I could be of some help. I'm even more glad you're enjoying REALbasic. :-)
Aaron,
I've been reading for a while but never commented on your posts. Today's rambling intrigues me so here goes a rather long reflection on your thoughts...
The beginning and end of your post reveals a defensiveness regarding 'bug' reports that has often baffled me.
When REALbasic doesn't work as I expect, it appears as a 'bug' to me. When I work hard at isolating a behavior that is inconsistent to me, it is for me at that moment a 'bug'. I fully understand that some items are in fact bugs while others are -- as you discuss -- my failure to understand an underlying design concept. But as a user, it is impossible at that moment for me to discern if the defect is in my knowledge or the program. It's right for me to report it so I can discover the solution to my current problem.
In the past 6 years I can count a dozen or more times where a 'bug' report was responded to from someone at REAL with a defensive/annoyed 'not a bug' reply.
In our company, we arn't peeved when our users think our software is broken because they don't know how to use it. In fact, we see this as a strategic opportunity to see things from users perspective. This has allowed us to better document behavior and be more consistent with our implementation. Sometimes we even change something we really like because it confuses a sufficient number of users.
I've seen a profound lack of this type of helpful dialog with REAL (though not you personally). My encouragement is that 'bug' reports that fall in the category of 'misunderstood functionality' are as important for developers to embrace and consider as actual bugs.
Perhaps an analogy will help:
It's as much my 'fault' as my wife's when she runs out of gas if I've refused to take the time to help her grasp the correlation of the car not running to putting gas in the tank. Simply being peeved at her stupidity deceives me into feeling like it's all her fault without helping her at all ;-).
Great post.
@Keith -- you bring up excellent points. That's a very good way to look at it. I guess my peeve more comes from a personal level than anything. Sort of "but I *made* it that way -- it's not a bug! Sheesh!" sort of feeling. Putting into into a different perspective like that is a good idea.
Yes, networking is interesting. For the DA event, I typically use a member variable for buffer storage until in the terminating string is found.
The bug vs. feature request idea is an ongoing debate. NICs are part of the hardware whether they are hooked to a network or not. So, one could think that it is a bug (as I did). However, if the Lang.Ref. specifically states the implementation, then I suppose the other functionality would be a F.R. :)