[followups set to c.l.s.d]
In comp.lang.smalltalk, [hidden email] (Rick Elbers) wrote: >Considering for instance my difficulty to create a simple textwindow >in dolphin to which I can log test messages( Ideally I want to create >my own workspaces at runtime), Just on that narrow point, I think you want something like the following (in Dolphin 3.06): ... | logWindow | "open our own TranscriptShell for logging. NOTE: we don't use the more normal #show to create it as we want a brand new window of the default view rather the current Transcript singleton" logWindow := TranscriptShell showOn: (String new). "now log some messages" logWindow show: 'This is a message'; cr; flush. logWindow show: 'This is another message'; cr; flush. logWindow show: '...And finally a third message'; cr; flush. ... You'll next probably want to use a customised view resource rather than the default one for a TranscriptShell. For example you probably want to change the titlebar caption to something other than 'System Transcript', and then perhaps get rid of the toolbar and edit the menus to drop the items that only really make sense for the Dolphin IDE. To do that open up the Resource Browser, scroll down to where in the left hand column (labelled 'Owning class') says 'TranscriptShell' and choose 'New>View' from the right click menu. Make your edits and then do 'File>Save As' naming the new view 'Log Window'. It should appear as a new entry in the Resource Browser underneath the old one. The updated code to use it would then look something like the following: ... | logWindow | "open our own TranscriptShell for logging. We're using a custom view resource that we've saved as 'Log Window'. We can use #show: here because we're now not using the default view resource" logWindow := TranscriptShell show: 'Log Window'. "now log some messages" logWindow show: 'This is a message'; cr; flush. logWindow show: 'This is another message'; cr; flush. logWindow show: '...And finally a third message'; cr; flush. ... HTH! -- Kapusniak, Stefan e |
In article <[hidden email]> on Tue, 28 Nov 2000 16:38:26
+0000, [hidden email] said: ||| Just on that narrow point, I think you want something ||| like the following (in Dolphin 3.06): ||| ||| | logWindow | ||| ||| "open our own TranscriptShell for logging. Thanks for the info. That is something I'd been wanting to do for quite some time, and this solution never occurred to me. I even went so far as to add TranscriptShell class>>logWindow to open one of these Log Windows more easily. ST is cool... Joey -- -- Sun Certified Java2 Programmer -- Political Rants: www.joeygibson.com -- My Pocket Smalltalk Stuff: st.joeygibson.com -- -- "Do you know what I am doing, Miss Kenton? I am placing my -- mind elsewhere while you chatter away." -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =----- |
In reply to this post by Stefan Elisa Kapusniak
On Tue, 28 Nov 2000 16:38:26 +0000, [hidden email] (Stefan
Elisa Kapusniak) wrote: > > [followups set to c.l.s.d] > >In comp.lang.smalltalk, [hidden email] (Rick Elbers) wrote: > >>Considering for instance my difficulty to create a simple textwindow >>in dolphin to which I can log test messages( Ideally I want to create >>my own workspaces at runtime), > > > Just on that narrow point, I think you want something > like the following (in Dolphin 3.06): > > ... > > > | logWindow | > > "open our own TranscriptShell for logging. > > NOTE: we don't use the more normal #show to create it > as we want a brand new window of the default view > rather the current Transcript singleton" > > logWindow := TranscriptShell showOn: (String new). > > "now log some messages" > logWindow show: 'This is a message'; cr; flush. > logWindow show: 'This is another message'; cr; flush. > logWindow show: '...And finally a third message'; cr; flush. > > ... > > You'll next probably want to use a customised view > resource rather than the default one for a TranscriptShell. > For example you probably want to change the titlebar > caption to something other than 'System Transcript', > and then perhaps get rid of the toolbar and edit > the menus to drop the items that only really make > sense for the Dolphin IDE. > > To do that open up the Resource Browser, scroll down > to where in the left hand column (labelled 'Owning > class') says 'TranscriptShell' and choose 'New>View' > from the right click menu. Make your edits and then > do 'File>Save As' naming the new view 'Log Window'. > It should appear as a new entry in the Resource > Browser underneath the old one. > > The updated code to use it would then look something > like the following: > > ... > > | logWindow | > > "open our own TranscriptShell for logging. We're > using a custom view resource that we've saved as > 'Log Window'. We can use #show: here because > we're now not using the default view resource" > > logWindow := TranscriptShell show: 'Log Window'. > > "now log some messages" > logWindow show: 'This is a message'; cr; flush. > logWindow show: 'This is another message'; cr; flush. > logWindow show: '...And finally a third message'; cr; flush. > > ... > > HTH! > > >-- Kapusniak, Stefan e Stefan, I already found the Transcript shell, but show seems overdetermined..? Show for me is associated with showing a window. And sometimes it seems so for the transcript, but at othertimes the show is about a string. Also I would like to know what the new string has to do with the transcript in the first example ... And the last point being obvious: the documentation is incomplete. For a huge development process that would cost probably at least as much time as the development-compilation circle. Its a good thing the MS documents all member functions with examples.. But a lot of thanx for showing this transcript to me...! Rick |
Ric
You wrote in message news:[hidden email]... > ... > I already found the Transcript shell, but show seems overdetermined..? > Show for me is associated with showing a window. And sometimes it > seems so for the transcript, but at othertimes the show is about a > string. Transcript show: 'blah blah', is actually an original Smalltalk-80 incantation which we have had the temerity to deprecate in 4.0. We've never liked it, and never use it. The standard Smalltalk stream protocols should be used to print to the Transcript, e.g. #print: (printString of object), #display: (displayString of object), #nextPutAll: (output a string), etc. Apart from aesthetic considerations this has the additional benefit that one can then redirect transcript output to a FileStream (or other stream) by substitution. Regards Blair |
On Wed, 29 Nov 2000 10:28:04 -0000, "Blair McGlashan"
<[hidden email]> wrote: >Ric > >You wrote in message news:[hidden email]... >> ... >> I already found the Transcript shell, but show seems overdetermined..? >> Show for me is associated with showing a window. And sometimes it >> seems so for the transcript, but at othertimes the show is about a >> string. > >Transcript show: 'blah blah', is actually an original Smalltalk-80 >incantation which we have had the temerity to deprecate in 4.0. We've never >liked it, and never use it. The standard Smalltalk stream protocols should >be used to print to the Transcript, e.g. #print: (printString of object), >#display: (displayString of object), #nextPutAll: (output a string), etc. >Apart from aesthetic considerations this has the additional benefit that one >can then redirect transcript output to a FileStream (or other stream) by >substitution. Sounds understandable. And exactly the same as streams in cpp. Problem in cpp is that sometimes you want the object streamed binary and sometimes as asci. And streams dont publish if they are either one of them, so in the end a lot of people dump implementing ostream& operator << ( const ostream& , const object& ) Another thing. How would you write out the your object to a new transscript window exactly with the use of display ? Rick > >Regards > >Blair > > |
In reply to this post by Stefan Elisa Kapusniak
On Tue, 28 Nov 2000 16:38:26 +0000, [hidden email] (Stefan
Elisa Kapusniak) wrote: > > [followups set to c.l.s.d] > >In comp.lang.smalltalk, [hidden email] (Rick Elbers) wrote: > >>Considering for instance my difficulty to create a simple textwindow >>in dolphin to which I can log test messages( Ideally I want to create >>my own workspaces at runtime), > > > Just on that narrow point, I think you want something > like the following (in Dolphin 3.06): > > ... > > > | logWindow | > > "open our own TranscriptShell for logging. > > NOTE: we don't use the more normal #show to create it > as we want a brand new window of the default view > rather the current Transcript singleton" > > logWindow := TranscriptShell showOn: (String new). > > "now log some messages" > logWindow show: 'This is a message'; cr; flush. > logWindow show: 'This is another message'; cr; flush. > logWindow show: '...And finally a third message'; cr; flush. > > ... > > You'll next probably want to use a customised view > resource rather than the default one for a TranscriptShell. > For example you probably want to change the titlebar > caption to something other than 'System Transcript', > and then perhaps get rid of the toolbar and edit > the menus to drop the items that only really make > sense for the Dolphin IDE. > > To do that open up the Resource Browser, scroll down > to where in the left hand column (labelled 'Owning > class') says 'TranscriptShell' and choose 'New>View' > from the right click menu. Make your edits and then > do 'File>Save As' naming the new view 'Log Window'. > It should appear as a new entry in the Resource > Browser underneath the old one. > > The updated code to use it would then look something > like the following: > > ... > > | logWindow | > > "open our own TranscriptShell for logging. We're > using a custom view resource that we've saved as > 'Log Window'. We can use #show: here because > we're now not using the default view resource" > > logWindow := TranscriptShell show: 'Log Window'. > > "now log some messages" > logWindow show: 'This is a message'; cr; flush. > logWindow show: 'This is another message'; cr; flush. > logWindow show: '...And finally a third message'; cr; flush. > > ... Problem is that I want a new transcript object, not a new class. I want to use the object methods, which is impossible this way. Also I have a very hard time setting breakpoints. Do smalltalkers use those ? Rick > > HTH! > > >-- Kapusniak, Stefan e |
> Also I have a very hard time setting breakpoints.
> Do smalltalkers use those ? I only figured out how to do this recently myself. Place 'self halt' in the code. -- Kevin Powe. |
In reply to this post by Rick Elbers
Rick
"Rick Elbers" <[hidden email]> wrote in message news:[hidden email]... > On Tue, 28 Nov 2000 16:38:26 +0000, [hidden email] (Stefan > Elisa Kapusniak) wrote: > >.... > > logWindow := TranscriptShell show: 'Log Window'. > > > > "now log some messages" > > logWindow show: 'This is a message'; cr; flush. >> ... > > Problem is that I want a new transcript object, not a new class. That's what you'll get. In Smalltalk you can define your own instance creation methods, and #show: just happens to be one understood by TranscriptShell; it returns a new TranscriptShell opened on the named view "resource" (the nearest analaogy in VC to that being a dialog template, although they are not quite the same things as a view resource is a frozen live instance, as opposed to a template specification). > I want to use the object methods, which is impossible this way. I don't want to confuse the issue, since in this case the logWindow variable does hold an instance, but one of the significant differences between Smalltalk and C++/Java, is that classes are first class objects in Smalltalk. In C++ one has static members that can be scoped to a class, but this is really only a namespacing of global functions, since the static members cannot be "virtual". Furthermore static class variables are really just limited access globals, and are shared by subclasses (i.e. they are not like instance variables). In Smalltalk a class object has the same capabilities as any other, and can have instance variables, and polymorphic behaviour, i.e. you can use treat the thing as an "object" whether you have a class or an instance. This is extremely useful. > Also I have a very hard time setting breakpoints. > Do smalltalkers use those ? Yes, but much less. In Smalltalk one is immersed in a world of live objects (the image) which can be interacted with at a fine level of detail. It is possible to debug individual message sends to individual objects, inspect them, and generally manipulate them in a much deeper way than one can do in a static language's debugger. If one wishes to debug an individual method, one doesn't normally need to set a breakpoint in it, one justs creates the object with a few expressions, and then evaluates an expression under the debugger which immediately takes one into the method in which one is interested. In D3 and D4 this is done using the "Debug-It" command (select the expression and press F11), and this can be done from almost anywhere, including in another debugger. A lot of Smalltalk programmers also do a great deal of programming in the debugger. Changes can be made and the debugger automatically restarts the method with the new code (this is a bit like VC's rather good "Edit and Continue", capability, except that it works 99% of the time, rather than 40% of the time, and it is instantaneous). This is not to say that the sort of powerful breakpoints one finds in typical C++ IDEs these days would not be useful, just that the need is so much reduced that implementing them is a lower priority than adding other features. I know of one Smalltalk that has a more powerful breakpoint capability, VisualAge, and I think one can purchase an add-on package for VisualWorks, as well as there being some public domain code in the UIUC archive. An important point about this is that it is possible for third parties to add major functionality to the IDE because the language's environment is all implemented in itself, we aren't talking about just a bit of scripting or a few macros. If one does't have "proper" breakpoints, then one inserts 'self halt' statements, conditionally guarded if necessary, in the code. This is a bit like putting a DebugBreak() in, except of course that there is no compile-link cycle and hence it doesn't interrupt one's flow. All this is pretty meaningless until one has experienced sufficient Smalltalk programming to "get it". It involves quite a different process and way of thinking, and this change in the way one works can be quite uncomfort able (like any change). If one looks for all the things one is familiar with in C++ and uses that as a measure of Smalltalk, then one is likely to be disappointed. When I first used it I thought it was bollocks, and it took me about two weeks of intensive use to convince myself that it was in fact "The Bollocks". It is also more fun than any other programming language and environment I have ever used. Regards Blair |
In reply to this post by Rick Elbers
In comp.lang.smalltalk.dolphin, [hidden email] (Rick Elbers) wrote:
>Another thing. How would you write out the your object to a new >transscript window exactly with the use of display ? Assuming you want to use the default Transcript view resource, something like: (TransciptShell showOn: (String new)) display: yourObject; flush. ...Or with a custom view and retaining the the transcript in a local variable for further use: | logWindow | logWindow := TranscriptShell show: 'CustomViewName'. logWindow display: yourObject; flush; ...on the other hand depending on what you're trying to do you might find the following more useful: yourObject inspect. Which is the code equivalent of selecting an expression that evaluates to yourObject and then choosing 'inspect it' from the right click menu or hiting Ctrl-I. Hope that helps. -- Kapusniak, Stefan e |
In comp.lang.smalltalk.dolphin,
[hidden email] (Stefan Elisa Kapusniak) wrote: > | logWindow | > > logWindow := TranscriptShell show: 'CustomViewName'. > logWindow display: yourObject; flush; ^^^ GAAAAAAAAAAAAHH!!! That last semi-colon should have been a period. Sorry, too much coding in Delphi this week... ...this month...this year. -- Kapusniak, Stefan e |
Free forum by Nabble | Edit this page |