In the AppleSoft and GWBasic Basic days or the 1980’s, I used to have listing paper several yard long listings. That was in the procedural programming era.
Today, with OOP and event driven programming, I cannot imagine why I would want to print a whole program.
Exactly. Sound’s like OOP and encapsulation has not arrived in the poster’s head. 
Don’t use globals. And btw, you can search things globally.
(https://xojo.com/issue/7173)>]Feedback case # 7173Yep… , open since April 2009. Currently at rank # 4.
Speaking only for myself, nothing could be further from the truth.
(https://xojo.com/issue/2428)>]feedback case # 2428I would find the situation slightly less irritating, however, if Xojo would implement suggesting that all property and method definitions (including those inherited) should be visible in subclasses. The case is from May 2008 and currently ranked at # 167, so I don’t hold out any real hope for it though.
[quote=166745:@Christian Vick]Exactly. Sound’s like OOP and encapsulation has not arrived in the poster’s head.
Don’t use globals. And btw, you can search things globally.[/quote]
why i should not use global ?? what should i use instead??
Any global property is a risk of bugs, since it can be modified anywhere in the program. It also makes it difficult to track.
Any time you create a global, check if it would not be possible to create a window property instead. The idea being that the closer to the place you modify a variable, the less risk it will be set somewhere in the whole app and create some glitch. Besides, and this is OOP, you can duplicate the window and not worry that one window will mess up your global variable.
Finally,if you need to access a property in several places of the program, globals are not the only possibility. Public properties can also be used, such as App.myvariable.
Globals are not taboo per se. They are just potentially dangerous.
i usually use property on the window if i know it is going to be use just in the window… sometimes, i need to pass thing between window then i use global property.
[quote=167006:@Richard Duke]i usually use property on the window if i know it is going to be use just in the window…
[/quote]
And if you set those properties to private then that’s perfect encapsulation.
[quote=167006:@Richard Duke]
sometimes, i need to pass thing between window then i use global property.[/quote]
You should make use of the namespace. That means you create classes and you instantiate objects from those classes at runtime. Before typing any code it is a good thing (and fun) to think about the structure of your app - logical encapsulation of classes. The classes become objects at runtime, and the objects can talk to each other, but they should do that only where really required. Otherwise objects should be encapsulated as much as possible from any other class. Added benefit, when you type & autocomplete you will only see properties & methods which are not marked private, which will shorten the autocomplete list, and more important, will safe you from using your classes wrong.
Does the GUI need access to everything in the data processing class? No. It may need to know how far the data processing is, so you could let the data processing class compute the progress percentage and allow the GUI to ask for that single property only, by making that property public.
I believe I have 5 or so global properties in my main project. And of course I have some global functions in modules, like logging. But if you share or process data in globals you will have bugs which you wouldn’t have in OOP.
xjprint just created a 4000 pages document for me and I like the way the code is presented! The index has the above mentioned overwriting issues. I will test again with smaller font sizes and using landscape.
I wanted to buy a license but no luck: “XjPrint_OSX is an Invalid product” is said on the homepage …
[quote=166628:@Dave S]Interesting…
I just took my current project… and used XJPrint to create an A4 PDF file, and while the index was not “perfect” it did not overlap like you samples show.[/quote]
Dave, I think the problem with the index has to do with the font size.
When I set the font size to 8 the index is overlapping.
After I changed the font size back to 10 the index looks very nice.
I wanted to buy XjPrint too, but also get the message as mentioned by Oliver.
You can set a property on the target window like Window2.myProperty = 56789. Or place a method on all windows that take a set of parameters, then call it like Window2.GetParam("title",&c234567,56.12,True).
don’t think i ever done that before…
Back to basic:
Can the op explain why (s)he needs to be able to have the whole project code at one single location ?
Can the OOP guru(s) explain how it is easier / better to do the things with Code as it is set by Xojo ?
Then, we may understand better.
Nota: Since the early days of HyperCard, I know why it is good to place code in objects, ;-
(more or less).
I would hope their only asking to see the whole code for a particular class.
There is not really much sense in the whole code for the application. Other IDE’s only show whole code for particular class or module.
[quote=167045:@Oliver Osswald]xjprint just created a 4000 pages document for me and I like the way the code is presented! The index has the above mentioned overwriting issues. I will test again with smaller font sizes and using landscape.
I wanted to buy a license but no luck: “XjPrint_OSX is an Invalid product” is said on the homepage …
[/quote]
Give me a day or two to investigate… ( I just got some bad health news and have to come to terms with it )
XJPrint probably does NOT have a Yosemite issue as stated on my webpage, as it was a more recent project. The problem with the other products is the security system. (it writes places Yosemites disallows)
[quote=167097:@Emile Schwarz]Back to basic:
I dont think one is better than the other, you just use them differently.
Sometimes you just want to quickly skim trhu yr project having a quick look, but not focusing into anything in particular…in this case you need to see the whole code at once.
Other times when you are working on a new method you just need to focus on a specific area.
Looking at the whole code is not bad in itself. Let alone to look at the masterpiece and awe at the thousands of beautiful lines of code
Coming from the procedural era, I do not want to relapse into thinking a program is a long list of chores that happen sequentially. There is the danger of the long listing. A danger all so often manifested by questions regularly posted here about the order in which events occur, or calls for a pause command (Console apart).
The major advantage of event programming is to abstract the global procedure and free the programmer from housekeeping the whole house. Each event is a self contained scenario. When I look at Window.Resized, I do not need to be concerned about MouseDown, for instance. And the other way around. Likewise, each method correctly encapsulated is independent from the paraphernalia. I do not need to concern myself with it’s inner workings. It does what it is supposed to do.
Altogether, OOP makes it really simple to code, as very seldom one has to deal with thousands of lines of code in one shot.
XjPrint should now be active in my store again… I’m not sure what happened, had to re-write part of my PHP script…
Did you try to print the project (to pdf for example) ?
Off topic, but related to some points here…
Where you put a variable makes a big difference to HOW HARD IT IS TO DEBUG
(yes, it gets me that much…)
Because Xojo doesn’t have popover variable content viewing, or a watch window, or pause on content change, or… you’re tied to the variable inspector, which shows you local variables only.
Even variable which are properties of the window have to be found by digging into the window as an object, then expanding.
I have in the past been guilty of putting variables on the app, because its easy to find them in debugging screens.
Jeff: things are worse if you want to know what is in a date object for example, you heve to click in it, then click in the popupmenu to come back to the variables, etc.
Debugging is not an easy nor friendly process 