Colleagues: Some days ago I published a "worst case scenario" account of what it might be like for a VB programmer to make the switch to the Rev IDE and the confusions he might encounter when presuming that the setup of distinct project design /project testing existed as he had been used to. For those of you who might have missed the thread, the original illustrated story of the VB programmer's demise is at http://www.howsoft.com/runrev/article.htm .
Of course, the question of VB programmers entering into the Rev world touches on various other crucial issues under discussion at the moment, such as the quality and availability of the Rev documents, whether or not Rev is too MAC-centric, whether or not Rev should do more to attract non-MAC clients, cross-platform technical issues, etc. Other colleagues are far more qualified to discuss these issues than I am. However, from my own egocentric point of view I have discovered that: 1. Although there are profounder aspects of the IDE's project testing environment that I really do need to work at, I am still suffering mental blocks over the denomination and inter-relationship of the Browse Tool, Pointer Tool, Modeless (properties??) and "Top Level", together with the fact that projects tested with the Browse Tool (or Modeless request) retain their acquired properties. 2. I am not the only one to be confused. Some people with far more experience in Rev and far less experience in VB do not understand the design of the interface in these respects, but so far have had little trouble because they have not asked too many questions. For example, I am perfectly happy using my video cassette player by learning how to start, stop, rewind, etc. All the other knobs and buttons I ignore. Or if I use Microsoft Word, I can quite happily produce my texts by ignoring about 80% of the resources available to me. The procedure I am used to in VB makes me very happy, and unfortunately, has become a precondition for my happiness: 1. Project design and project testing are totally separate modes. 2. I feel absolutely no need to include user data in my project. I prefer to keep it separately on the HD or elsewhere. If necessary, I can bundle it with my standalone program and distribute it as a single file, but this is done separately and by other means. (However, it should be noted that Rebol for example permits the mixing of program and user data in the same script, and this is considered to be an advantage in some circumstances.) 3. I can work in the following manner: Program a bit / Test it / Program a bit more / Test it / Program a bit more / Test it ....................................... This particular characteristic is so valuable that anything which prevented me from doing it easily would upset me to say the least. Some people have pointed out that Rev is different to VB, being born in the MAC tradition. Rev means MAC, and proudly so, so welcome to Macintosh and roll up your sleeves. If I were the average VB programmer (which I am not), I would simply say "OK, bye-bye". What does the average man do when his favourite program ends on the TV and he doesn't fancy watching the next one? He takes a quick look at all the other channels. And how does he judge whether he will switch to another channel? I don't know about you, but I usually make up my mind in a few seconds. Is it the type of program I am looking for? What is the overall quality of the pictures I take a glimpse at? Do I like the actors' faces? Or perhaps I am looking for something completely different to the program I have been watching, or not. So all this relates back to whether Rev is interested in occupying a conservative niche of about 10% of the overall market, or whether it considers that it needs to expand (and really capture potential users such as myself) in order to survive. These things said, I would like to introduce you to an absolutely brilliant analysis of the initial difficulties I encountered with the Rev IDE. It was sent to me by Ken Ray, and it appears below. But for those of you who missed the start of this thread, I should explain the following. The last 2 pictures of the article at http://www.howsoft.com/runrev/article.htm express the idea of providing Rev with a mechanism for project testing in the VB manner I have described. Troy Rollins thinks that (even as a beginner) I could quite easily produce the plugin stack depicted there. I might well try to do it. But Ken has an important observation to make about this question, as you will see. Within a few days, I will put Ken's analysis on my site at http://www.howsoft.com/runrev, since it is so useful. There are even indications that Ken intends to pursue the Rev/VB comparison further and that perhaps many more useful insights are in the pipeline. Anyway, here is Ken's analysis: (Bob, I'm writing this to you "off list" - if you feel that it should be "on list", feel free to post it or to tell me it's OK to post it.) >> If you really need it, you could do it. > > That was exactly what I had in mind, except that I am a complete beginner in > RR and I was a bit nervous about attempting such a thing as a first > programming effort. I agree, Bob... you shouldn't have to try to develop a plugin as your first programming effort, considering the trouble you went through to understand the pointer/browse dynamic in the first place. To me, something like this is like a conversion program that converts from one xTalk to another - once it is used it is no longer needed. As you said, until such a time as you can apprecite the "persistent properties" (which is really the result of a unified design+run mode), you would like a tool like this. Which implies that once you "get there", you won't need it anymore. I printed out your article and read it over in detail to see what I could glean from your experience. Here's what I discovered: 1) Coming from a VB background, you naturally looked for a way to assign a value to a property for an object. So much like in VB where you'd do: TextBox1.Text = "Hello World!" I'm assuming you looked for a "text" property of a Rev field, found it, and decided to test it: set the text of Field 1 to "Hello World!" Which worked (of course). But it seems that without guidance, the whole concept of "containers" (e.g. a field as a container for text data) was missed, and the whole "put"/"get" approach was not explained. This is how it is "normally" done: put "Hello World!" into field 1 Those who come from an xTalk background already have this under their belt, but non-xTalk programmers do not. POINT #1: RunRev needs to document better the container concept, along with its "set the <property>" alternatives. 2) You assumed that there was the classic "design mode" and "run mode", and so went off down the path of looking for a way to toggle between the two (this was stated by me in an earlier post). But rather than discover that there *aren't* two modes, you mistakenly assumed that the "browse tool mode" is one mode and the "pointer tool mode" is the other mode. This is certainly a very understandable mistake, as you pointed out - you were looking for a way to test your project and you found it. But that brings me to the next point: POINT #2: RunRev needs to explain clearly the "single mode with different tools" approach, and not merely assume that everyone will "get it". In fact, only xTalk programmers from other tools will "get it" - everyone else will have to make a conceptual shift. 3) After migrating from MetaCard to Rev, you ran the same test and for some reason couldn't find the browse tool in the tool palette. I'm curious - why did this happen? MetaCard's tools were in the toolbar and Rev's were in a palette, but it doesn't seem to me that there is that much of a cognitive shift between the two. Is it because of the similarity to the move tool in Photoshop? You eventually went down the path of using the Application Browser to do "Go" (which just displays the card you selected; the currently selected tool doesn't change - which is why you thought nothing happened). By choosing "Modeless", you invoked a mode that forced the stack window to effectively close and reopen *as a dialog box*. Modal and modeless dialogs automatically get the browse tool regardless of what is the currently active tool. POINT #3: RunRev needs to explain clearly how different stack modes change the tool selection. 4) You hunted around and found the Property Inspector and used that to clear the text of the field. You were unaware that you could use the browse tool to click and select the text in the field and hit the delete key to remove it (unless the field was locked through the 'lockText' property being set to true, but I'm assuming that wasn't the case). Once again a disconnect between modes - thinking in "two modes", it wouldn't make any sense to wipe and delete the text, because as soon as you return to "design mode", whatever changes you had made would be irrelevant (as they are in VB). However thinking in "one mode", where the field's contents are there regardless of tool chosen, it would make *perfect* sense to switch to browse tool and wipe the text and delete it. Of course this wouldn't affect the stack when it started up again unless you saved it first, but at this point in the story, that is not the most important thing. (see POINT #2) 5) You discovered that RunRev didn't have good drawing tools or antialiasing. Yup... that about covers it. :-) 6) Instead of counting sheep, you repeated the mantra: RUN - BROWSE TOOL - POINTING FINGER - MODELESS STOP - SELECT CONTROLS - DIAGONAL ARROW - TOP LEVEL Can I assume that now you know the mantra is: BROWSE TOOL - POINTING FINGER POINTER TOOL - DIAGONAL ARROE And that there isn't really a "run" and "stop", and that the "modeless" and "toplevel" are ways of displaying stacks and don't really correlate to browse/pointer? If not, let me know and I'll be happy to explain them. The reason why there isn't really a "run" and "stop" is that even with the pointer tool selected, scripts can still run. It's just that you usually can't *activate* most handlers because they depend on the browse tool. For example, "mouseUp" is one of those that depends on the browse tool - "mouseEnter" (the message sent when the mouse enters the rectangle of the object) is activated regardless of tool. Try this: - Create a button in Rev. Edit the script so it has this code: on mouseUp beep end mouseUp on mouseEnter beep end mouseEnter Then switch to browse tool. As your mouse enters the button you will hear a beep. Click the button and you'll hear another beep. Then move the mouse out of the button area and switch to pointer tool. As your mouse enters the button you will hear a beep. Click on the button and the button will be selected, but will not beep. So you see, there isn't a "mode" in Rev where NO scripts run. Scripts run due to messages being sent to specific objects, and these messages get sent all the time, *sometimes* dependent on what tool you have chosen. There are methods to "lock messages" temporarily so that certain messages are prevented from being sent, but there is no way to lock all the messages forever (or until a specific action has taken place). The best that can be done is to create a "frontscript" (I'll explain this later if you like) that can trap and absorb all of these messages and not pass them through to other stack objects. POINT #4: RunRev needs to understand, document and make easily available a set of instructions to guide programmers from other environments to being able to understand how Rev is used. It can't just assume that everyone will "get it", or will know where to find things in the docs or even *go* to the online docs. After first time installation, it should not just bring up a "tip of the day" window, but should provide a wizard that asks the user their past experience and guides them to finding the right data in the docs. Bob, the Rev documentation is really very good - most of the problems that people have had with it are that sometimes the information is in a non-intuitive place, or that an imporatnt concept is buried several levels down and hard to get to. This is the exception and not the rule, though. For example, when I opened the docs and clicked on "Welcome to Revolution", the first thing that greeted me is "What describes you best?" with a list of different places one could have come from. When I clicked on "experienced traditional language programmer" there was a wealth of information on making the conceptual shift between traditional languages and Rev. So it's not that the information isn't *there*, it's just that it is not where it needs to be, IMHO, for the beginning user. Anyway, that's my take on things, Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution