I apologize if the following question has an obvious answer. I've developed a console application that works perfectly, but in console. I come from basic VB coding, so I'm used to subprocedures: Button.click -> go to this_sub. However, with GTK2 (as well as Ruby itself), it's different. The way my console app works is rather simple: it's basically one huge IF statement, connected to each and every cell value in an Excel spreadsheet. if cell1 == "Value1" and cell2 == "something else" then puts "The output" elsif cell1 == "Value2" and cell2 == "something else" then puts "A different output" els puts "Value not found" For every 'IF' situation I just have the 'puts' command after that, which populates the output in console. The reason it's a huge IF statement is because of my lack of knowledge on how to use Excel-based database if values within my Ruby app. Technically (and practically) speaking, my app is not talking to the Excel file at all - it's all hard(hand?)-coded. I totally understand that my whole code is quiet redundant to say the least. For now, is it (and I think it certainly is) possible to replace/recode the 'puts' method to something more relevant, for instance: e = Gtk::Entry.new if cell1 == "Value1" and cell2 == "something else" then e.text "The output" elsif cell1 == "Value2" and cell2 == "something else" then e.text "A different output" els e.text "Value not found" I've included the file that I have, but it doesn't have anything related to Gtk, sorry about that. I'm a beginning Ruby programmer, and any suggestions are welcome. And thank you for your time.
on 2008-10-03 18:49
on 2008-10-04 02:44
Hi Will. I'm replying privately because probably the discussion doesn't have much to do with GTK2. It's great that you're getting into Ruby! As you go along I think you'll find that it's much more flexible than VB. But as you noticed, it may take some time to learn all the concepts and techniques that will make you an efficient programmer. Don't worry; just take it slowly, one bit at a time. I thought about guiding you through the refactoring to make this program easier to read/write, but then decided against it. Since you are just starting out, I think it would be better for you to find your own way. But here are some suggestions to help you find the path. I'm sorry that the discussion is so long... :-P 1. Start off trying to write subroutines. Since you are probably used to writing small VB scripts, you may be thinking it is unnecessary. But as your desire to write more and more complicated programs develops, this will help keep the program simple to manipulate. Subroutines look like: def my_subroutine(a, b, c) return a/b + c end Then you can call it just by typing: my_subroutine(myA, myB, myC). The last line of your script should call one of the subroutines. When you first get started doing programming like this, you should get into the habit of having your main script only be 1 line. All of the other subroutines should be about 5 lines long, and never more than 10. 1 line long subroutines are really useful for improving readability. For example: def q1_2006?(date) return date.between?(Date.Parse("1/1/2006", "3/31/2006") end Then you can say if q1_2006?(date) end When you first start out, it will be quite a brain teaser to keep trying to keep your subroutines so small. You will probably be thinking that you are wasting more time doing that than writing the whole blasted thing. But trust me. When you keep the subroutines small, it keeps the problem solving easier. Opportunities to do what you want will spring out of nowhere. One of the biggest problems you have with making your program fit with GTK is that you've got a big blob of code and it's hard to massage it into the shape you need. One very important point is that if you return a value from your subroutine it should *always* be the last line of the subroutine. Never return early. When you get more advanced and understand where you can break this rule, it doesn't always hold. But when you are getting started, you need to follow it religiously. 2. Don't use global variables -- ever. OK. I admit that on ocassion global variable are actually essential. And if you know what those ocassions are, then it's all good. But when you're first starting out, you will never run into these issues. Trust me :-) Don't ever use a global variable. The problem with global variables is that it allows you to "cheat" a little bit on the design of your code. It makes a few things easier up front (i.e., you can get the data you want without work). But the downside is that it makes your code more difficult to manipulate later (pretty much same issue as the subroutines). So when you forbid the use of global variables, your code magically becomes easier to use (though harder to design up front). How do you do it? Basically you pass all the variables you need into the subroutine. Yes, sometimes that means you are passing a lot of variables around. But if you keep your subroutines small, it won't happen so much. The key here is that you will start hating to pass yet another variable around and you will start to think, "How can I do that differently". This will result in code that is much more flexible. 3. OK, those are the basics. You can also start to look at object oriented design for your code, but it takes a good 6 months of constant use to really internalize the ideas. It's best to start just with good modular programming, which is what I've summarized. But once your code is modular, you can start to do more overall structural design. And this is where you will start to find it obvious how to integrate with GTK. Generally speaking, you code should be designed with 3 areas: input, processing and output. You should have subroutines that get input; subroutines that process the input into a final result; subroutines that output the final results to the user. Then you have an overall script that calls the input, processing and output methods. (Remember: subroutines have to be small! So be careful here. Don't be afraid to write a *lot* of small subroutines!!!) Once you have this, you can start to see what to do: You have your data structures which contain the GTK input widgets. You pass it to your subroutine to get the input you want. Now you process the information. Then you pass the result to a subroutine along with the GTK output widget to output the data. This is a modular way to do it. Object oriented is a little different. You have an object (called a "Controller") that contains the GTK widget. It has methods on it to get the input. You have another object (called a "Model") that processes the input. You have a final object (called the "View") that contains the GTK widget with will display the result to the user. This pattern is known as "Model View Controller" or MVC for obvious reasons :-). 4. My last piece of advice is to look at the example code that comes with ruby-gnome. Most of this code is truly horrible and doesn't follow any of the rules I stated above. But look at it anyway and try to write a "prototype" of the UI that you want. Don't do any processing at all. Just do the input and the output (with fixed data that you make up). Then try to transform the code into small subroutines like I mentioned before. At that point, I think it will be obvious how to fit the processing in there. Sorry for the long rant :-). You *did* ask for suggestions... I've been a programmer for a couple of decades now and I started out exactly the way you did -- just noodling around with some stuff I wanted to do. Keep plugging away and learn a little bit by little bit. Keep practicing as much as you can. Read other people's code. And feel free to ignore my advice if it doesn't work for you :-) MikeC
on 2008-10-04 03:24
Mike Charlton wrote: > Subroutines look like: > > def my_subroutine(a, b, c) > return a/b + c > end > > Then you can call it just by typing: > > my_subroutine(myA, myB, myC). Aha! I read this in the book. They called it methods. > And feel free to ignore my advice if it doesn't work for you :-) Come on now, you've spent so much time and energy on this post, I *will* take your advice into account and start practicing! Lots of thanks!
on 2008-10-04 04:22
On Sat, Oct 4, 2008 at 10:24 AM, Will Dexter <firstname.lastname@example.org> wrote: > Come on now, you've spent so much time and energy on this post, I *will* > take your advice into account and start practicing! Lots of thanks! Hi Will. I'm glad you found the advice useful. Feel free to email me for any questions you might have. I enjoy talking about programming, so I'm happy to help if I can. MikeC