Gammon Forum : MUSHclient : Python : Easy Text editor?

Entire forum ➜ MUSHclient ➜ Python ➜ Easy Text editor?

Easy Text editor?

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3 4 5

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #45 on Thu 01 Mar 2007 12:14 AM (UTC)

Message

Quote:
I know quite a few languages though, so not knowing the specifics of any given language doesn't mean I don't have a decent picture in my mind of what it *should* do to impliment the idea, even if the specifics are a little more vague.

I think you are confusing two different things. There is knowing a programming language, and then understanding a library. I know C++ well, I daresay perhaps very well, but I have no idea how to write 3d applications using DirectX. Well, actually, I do have some idea, because I'm familiar with OpenGL and know the general principles of 3d, but whatever -- the point is that familiarity in a language won't give you familiarity in sets.

Here's a better example: despite knowing C/C++ well, I would have to learn from almost scratch if I wanted to write GUI applications for Gnome using GTK.

Basically there is a difference between the language you write in and the tool set, libraries, etc. that you use.

Quote:
I am one of those people that, when completely familiar with the syntax, can code a thousand line program in a few hours, then spend less than half that debugging it. I rarely have to "plan out" the design of anything. I admit that this may be biasing my thinking a bit, since what *seems* obvious to me in the big picture can look really complicated to someone else.

Not to diminish your claim, but a thousand line program is still relatively small. I regularly write 200-1000 line programs to help me solve homework, or even for homework.

But try writing a 45,000 line program. Or, even a 15,000 line program. It's a completely different beast. Not having a design is a sure recipe for disaster.

Also, sometimes a clear big picture isn't worth very much. The big picture of virtual memory management or disk caching in an operating system really isn't that hard. But the actual implementation is extraordinarily complex.

Give it a shot and see what you think:
http://www.stanford.edu/class/cs140/ Operating Systems

Quote:
Languages that I don't know well, get me a tad more frustrated, especially when they are ones like C++, where if you are not using something like MFC, require you spend a lot more time telling the system how to do things, than telling it what you want it to do.

I'm not sure what you mean by this. I'm guessing you mean having to deal with things like memory allocation and deallocation, and having to work in a fairly rigid syntax. But I agree with the general sentiment that some languages incur a greater start-up cost than others depending on what you are doing.

That is why it is important to understand your toolbox. For small, quick programs I use Perl or Lua. When it gets larger, I either structure the Perl/Lua more (using a module-based system, for example, or object orientation) or move to C++ or Java.

Quote:
It doesn't help at all that right now I have the choice between something like GCC, which has, at best, a command line debugger (yuck!) and no sort of GUI based code editor with helpers

I know what you mean but your comparison is a little unfair. GCC is just a compiler; it doesn't purport to be any of the above. It's one piece of a tool chain.

gdb is a debugger, and if you really want a GUI environment on top, you can use e.g. ddd, a graphical front-end for gdb. For the GUI, you should think about what features you need specifically. The two things I use a lot are:
- intelligent auto-completion (OmniCppComplete plugin for vim7)
- jumping to a specific function, method or class (vim tag system, using exuberant ctags)

Since those are my main needs, I have found ways to meet them that work very well, arguably better than Visual Studio. Of course, it doesn't hurt that I have been slowly learning vim for years now, and have been working in this whole tool chain for years as well. When I started it was rather daunting.

Quote:
The problem isn't that I don't think fast enough, its that I think too fast and can literally change perspective in mid sentence, at times I am trying to get something complicated out.

Oh, that's what I meant. I didn't mean to say you don't think fast. :-) I've run into a number of people (myself included, in the past and sometimes now) who write too quickly and don't stop to collect their thoughts. I (usually) make an effort to think through what I'm going to say before I say it, in the hopes that the result will be more coherent and more precise.

Quote:
However, you are still admonishing me about the subtlety and complexity of something that *if* you understood it either you would have the answers I need.

My main complaint is that you appear to be saying it is simple when you don't know the answer yourself. I'm not sure how you can say it's easy when you don't know how to do it. :-) Of course I don't know how to do it either, and for that matter I haven't really looked into it, but on the other hand, I have written a fair amount of code in my time including some that deals with Windows event loops. (Admittedly I have not written an MFC program, and only know the basics of how it works, that much is true.)

Quote:
That it "looks" subtle and complex may be a given. But neither of us is in a position to say that it really is, unless we understand the mechanics of how to produce it.

Yes, but as I said above the converse applies too, and that is what I am trying to point out. Neither of us have the process in hand, so arguing that it's easy just because you want it to be easy doesn't really hold much sway. (It would be nice, of course, if it were easy...)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #46 on Thu 01 Mar 2007 12:15 AM (UTC)

Message

(This is part 2 of the above post.)

Quote:
Can we at least agree that your's may be as well and that just maybe this isn't as complex as you insist? Seriously, ignorance is not an insult, its just a statement of fact. Admitting to it means you can progress in understanding, rather than just making snide remarks about how the other guy that is progressing, how ever slowly, is on a wild goose chase.

The thing is that, to my knowledge, I have made rather few claims in this argument. I freely admit that I don't have the definitive answer to this problem, however, my experience due to many years of programming gives me the definite hunch that it isn't nearly as easy as you think. That is the claim I want to make. I'm not saying you are on a wild goose chase; what I say to that effect is that I think you should learn the basics before trying to work on a large system of many components with complex interactions.

I would be delighted to find out that this is, in fact, a very simple thing to do, and simply a matter of tweaking a line or two of code. Trust me, I think it would be really neat too to have custom GUI control via wxLua. Not neat enough to warrant me spending the time to research it, admittedly, but still pretty neat. It's just that given all the parameters and unknowns I think the solution will take a rather long time to find, much less implement, and what I resent is your insistence that it isn't hard. I think what you really mean is "shouldn't", not "isn't", but unfortunately these complex systems don't always work according to what "should" be the case based on what we desire...

Quote:
Microsoft have also released "Visual Studio Lite" or whatever it is called exactly, which is a free download of Visual Studio, including C++, VB, and so on.

Yes, they call it the Express version. See:
http://msdn.microsoft.com/vstudio/express/

Personally, I prefer to use vim with exuberant ctags, a few plugins, and a well-configured .vimrc file. But that's just me. :-)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Shadowfyr USA (1,788 posts) Bio

Date

Reply #47 on Thu 01 Mar 2007 07:38 AM (UTC)

Message

Hmm. Problem with the "Lite" versions is they often hamstring you with limitations, like *not* giving you MFC at all, or letting you run "test" applications in debug mode, but not compile them to anything that is stand alone. I personally hate the latest batch of "learning edition" ones they put out do to that. Second is, since they don't include the GUI or any of the links needed to use Visual Studio if you already own it, your stuck with a learning curve that looks more like the side of Mount Everest than a comparatively simple cliff face. lol

Did download the one from Borland for kicks, but then never did anything with it. And, most of the latest "MS" version, after 6.0, are tied into the damn .NET stuff, which kind of defeats the purpose of finding a solution for a client that is meant to run on the widest variety of systems possible, including ones that **can't** run a version of .NET.

Now, as to my understanding. I have read the ATL book, a bunch of stuff on OLE, though I admit not what I was looking for, dug through various thread on places about the subject of events, etc. I probably know more than anyone here about how it fits together, despite having missing pieces. Those pieces look, at the moment, more like the 1-2 that inevitably get stuck on someone's shirt or land upside down on the floor of the kitchen, not the gapping hole that you get when you have all the edges, but nothing else has been placed yet. My personal opinion is that, while its probably not going to be a mere one or two lines, its also not going to be like 200 either.

Most of the issues I see arise not do to the complexity of the solution, but the complexity of the hoops some clown put in the way of getting it to work. For example, implimenting a call to the invoke method of an ActiveX control, to tell it to connect an event to a sink "should be" one line. In any language that directly supports the implimentation is it. In raw C++, with no libraries helping you out, you have to do like a dozen other things, from making calls to the system metrics to get ...something... before the OS will "let" you call it. Why? Because you *might* make a call to invoke that is effected by those things, even if what you are trying to call has jack to do with any of them. I gave up on that approach after trying to trace the mess for doing it through the .h and other files in my ancient version of C++ that I do have. Haven't been so annoyed by the convoluted gibberish in someone else's library implimentation since I tried to figure out how the heck command parsing worked on an Apple IIgs, where the code was about 10 machine instructions that are identical to the older Apple I, II, II+, IIe and IIc, except where it made a long jump to some upper memory location where the new IIgs bios was, and proceeding to mangle things beyond all recognition. Near as I could tell, and I know I missed something, the "code" in that location always returned an invalid value, which should have stopped the parser from working at all...

The coders where either way smarter than me, completely insane, or both. lol I felt the same way trying to figure out how invoke calls worked according the the library descriptions for what ever it was I was looking at in the C++ mess. And, since then, I read stuff that implies that about 90% of it is completely unnecessary if all you are doing is telling the object to link an event. Its all there "in case" you need to do one of like 50 other things.

This is one reason why I am sure its simpler than it looks. Yeah, there are bound to be a dozen "complicated" solutions, but in nearly every case those are complicated because they are doing *more* than what I am trying to solve in the first place. Its like trying to fix a tire and having someone insist you read the *entire* repair manual starting with page one, before they let you see page 50, which tells you how to change the tires (which happens to be an after thought in the section about replacing the entire transmission).

Its about finding the "best" solution, not just any solution, and there are lots of *bad* ones that are way more complicated than strictly necessary. Most are "bad" in this case because they assume you are starting from pure scratch and you can't even create the object, much less look at its attributes or call its exposed functions, and calling its "hidden" functions is part of getting to that point, with, much like changing the tires, the use of events being either ignored entirely, or tacked on as an after thought. And that is with ActiveX, which is presumably a well known system. For standard system events.... I haven't yet even tracked down anything that says conclusively *if* ActiveX and standard events even relate to each other, since the former is designed to circumvent a lot of the limitations of the prior structures, due the them being "too" rigid in the first place. Its not just possible, but maybe even likely, that the solution for ActiveX is *nothing* like the solution needed for something like the wx libraries. What I have learned seems to imply this as a real possibility.

Anyway.. Got to dig out some cash and buy the OLE book I guess. There is also a so called "standard edition" of Visual Studio, which if I get the C++ version is cheaper (asseming 6.0 had such a version). Or.. Maybe I can find some relative in college who can get it through a school discount. My previous source... Lets just say, without disparaging any beliefs she thinks she holds, that I have more ethics than she does and thus won't intentionally use even the most selfish fool to serve *my own* selfish desires, unlike someone else I might name...

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #48 on Thu 01 Mar 2007 07:58 AM (UTC)

Message

Quote:
Problem with the "Lite" versions is they often hamstring you with limitations, like *not* giving you MFC at all, or letting you run "test" applications in debug mode, but not compile them to anything that is stand alone. I personally hate the latest batch of "learning edition" ones they put out do to that.

Well, there is the problem that MFC is now something of an deprecated technology; Microsoft seems to have moved on to likes like ATL, WTL and most recently C#. It's quite likely that they are pushing people to follow that trend. Frankly it's probably for the best in the long run; my understanding is that they realized some things weren't quite right and tried to fix them with subsequent toolkits.

Despite that, MFC remains very strong, and has the advantage of having lots, LOTS more documentation than, say, ATL/WTL.

Quote:
Second is, since they don't include the GUI or any of the links needed to use Visual Studio if you already own it, your stuck with a learning curve that looks more like the side of Mount Everest than a comparatively simple cliff face. lol

Did you even look at the Express version I linked to? It has the GUI you're looking for...

Quote:
And, most of the latest "MS" version, after 6.0, are tied into the damn .NET stuff, which kind of defeats the purpose of finding a solution for a client that is meant to run on the widest variety of systems possible, including ones that **can't** run a version of .NET.

No, that isn't true. I have a copy of VS2003 or something like that (which is version 7, I think) and it definitely does not limit you to .NET.

Quote:
Most of the issues I see arise not do to the complexity of the solution, but the complexity of the hoops some clown put in the way of getting it to work.

This is the kind of statement you make that grates against my ears. I think that it is very, very dangerous to make claims like this unless you have a really, really good idea how the internals work and understand why design decisions were made the way they were. Now that's not to say that there are no mistakes, but to say that it's just a bunch of "hoops some clown put in the way" seems to me to be a very narrow-minded point of view.

Quote:
I gave up on that approach after trying to trace the mess for doing it through the .h and other files in my ancient version of C++ that I do have.

I don't really know what you mean by "ancient version of C++". I'm assuming you mean the Microsoft tool chain. C++ itself hasn't changed very much. It's the libraries Microsoft provides that have changed.

Quote:
For standard system events.... I haven't yet even tracked down anything that says conclusively *if* ActiveX and standard events even relate to each other,

ActiveX is a platform built around the Windows way of doing things. So of course they relate in the sense that ActiveX is trying to extend the basic functionality of the operating system. But I think that trying to draw too strict of a comparison is not an appropriate task. My understanding, of course.

Quote:
Or.. Maybe I can find some relative in college who can get it through a school discount. My previous source... Lets just say, without disparaging any beliefs she thinks she holds, that I have more ethics than she does and thus won't intentionally use even the most selfish fool to serve *my own* selfish desires, unlike someone else I might name...

I have no idea what you just said. :-)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Nick Gammon Australia (23,120 posts) Bio Forum Administrator

Date

Reply #49 on Thu 01 Mar 2007 07:39 PM (UTC)

Message

Quote:

Problem with the "Lite" versions is they often hamstring you with limitations, like *not* giving you MFC at all ...

It is true the Express version does not support MFC, however to an extent it seems to me that MFC is part of the problem we are discussing.

I sympathise with your frustation at getting information on how to get these things to work. For example, just when I was coming to grips with MFC, they started saying ATL was "better", but, of course, completely different.

If you were going to make a GUI client (and I think someone here is doing just that), then I would be looking at wxWidgets (formerly known as wxWindows until threats of legal action from Microsoft), which is something that is similar in concept to MFC, but cross-platform. And, of course, wxLua, which you talked about is related to wxWidgets.

Unfortunately, when I last looked, wxWidgets did not use STL, but its own internal structures for lists, maps etc. <sigh>

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Shadowfyr USA (1,788 posts) Bio

Date

Reply #50 on Thu 01 Mar 2007 07:46 PM (UTC)

Message

Sorry, had the distinct impression that MS was "pushing" people to .NET and intentionally leaving out specific toolsets as "depricated". It was seriously pissing off a least a few of the professionals that tried to make the switch. 2003 is still an "older" version though, so almost, sadly, as hard to find copies of as 6.0. What I meant by ancient copy of C++ was Visual C++, like version 3.0 or something...

As for the event models. Yeah, ActiveX on some levels is using the OS the same way, the problem is.. With events its a bit odd. What I have read seems to imply that its event model may not even go through the normal event system. I.e., its never going to be seen by MFC or any other part of the application, because instead of firing an event to the system, it instead does a direct call to the memory address where the entry point to the function for that event is. I may be wrong. Its possible it passes that address to the application and the application is supposed to call it or the ActiveX control manager in the application is keeping a table of those addresses and the ActiveX control is just... Well, it doesn't look like that is happening according to **anything** I have read on how those calls work. What is possible is that such controls are "both" doing a direct call *and* generating a system message, but if so, then it wouldn't be literally impossible to use late bound ActiveX in something like VB without a bridging dll. You can intercept event messages in VB, but **not** apparently those from the ActiveX controls, or bridging wouldn't be necessary. All a bridge really does is provide the system call that is locked out of VB, letting you "link" the event to the function that it needs to call when it happens. It has no manager itself, just a bypass to get around the inability to use the objects "Invoke" methods, which are needed for event handling.

So, as I said. Just because on some level ActiveX does do things like the rest of windows **doesn't** mean that it works 100% the same as direct API created objects. All the messaging and other things needed are probably instead handled by the OLE automation dlls, which are basically black boxes as far as your application is concerned. Event management may actually belong to OLE, not your own application in such cases. Which is *very* different than how standard controls are handled.

As for the lady I mentioned.. Lets just say she is sticking her nose into family business she doesn't have a right to, defending someone who is a lier simply because she can't believe that someone of the same "faith" lies, only shows up when "she" needs something from you and is generally the sort that insist they are "good" people, despite the fact that everyone else around them, unless they attend the same church, think of right wing apologists, not "good" people when you mention their names. That clear enough? ;)

In any case, I refuse to sink to her level and only show up at her place because *I* need to buy something only she can get for me.

Top

Posted by

Shadowfyr USA (1,788 posts) Bio

Date

Reply #51 on Thu 01 Mar 2007 07:52 PM (UTC)

Message

Well Nick. I don't think there is "necessarilly" anything preventing some mixing and matching, though you might have to override some things and go to the deep code, not just a different library implimentation. But, since we are starting out on MFC here, trying to look for a way to fix it in something else... doesn't work too well. lol

As I said, I may have to go clear back to V6.0 to be sure to have a version that not using dependencies that are not obviously going to break stuff on 95, for example, and also include all the libraries acutally "in use" in this case.

Top

Posted by

Nick Gammon Australia (23,120 posts) Bio Forum Administrator

Date

Reply #52 on Thu 01 Mar 2007 08:00 PM (UTC)

Message

I'm not sure if this relevant, but I am still using VC 6.

I haven't felt the need to spend lots of money "upgrading" when the old version works fine.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Shaun Biggs USA (644 posts) Bio

Date

Reply #53 on Thu 01 Mar 2007 09:52 PM (UTC)

Message

Quote:
Sorry, had the distinct impression that MS was "pushing" people to .NET and intentionally leaving out specific toolsets as "depricated".

And here we have M$'s battle plan for getting all your money. If you notice, nearly every company out there comes out with something that is the "latest and greatest" every few years to get people to switch. Micro$oft, which has a huge corner of the market, is generally in a better position to force people to make the switch by simply not making things backwards compatible. Also, some methods are just better than others. If you take a look at the history of Java, which has been open for use for quite a while, you will see hundreds of methods in the main classes which are depreciated to comply with better standards. Even looking through Lua's documentation, it has a decent amount depreciated, and it's a fairly new language as far as things go.

Quote:
As for the lady I mentioned.. Lets just say she is sticking her nose into family business she doesn't have a right to, defending someone who is a lier simply because she can't believe that someone of the same "faith" lies, only shows up when "she" needs something from you and is generally the sort that insist they are "good" people, despite the fact that everyone else around them, unless they attend the same church, think of right wing apologists, not "good" people when you mention their names. That clear enough? ;)

What does this have to do with anything on this board? The moral issues of you and those you know are not really a good topic for here. There are plenty of boards out there that you can vent this off, or have a debate, or whatever will make you feel better.

It is much easier to fight for one's ideals than to live up to them.

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #54 on Thu 01 Mar 2007 11:05 PM (UTC)

Message

Quote:
As for the event models. Yeah, ActiveX on some levels is using the OS the same way, the problem is.. With events its a bit odd. What I have read seems to imply that its event model may not even go through the normal event system. I.e., its never going to be seen by MFC or any other part of the application, because instead of firing an event to the system, it instead does a direct call to the memory address where the entry point to the function for that event is. I may be wrong.

Well, what might be an issue here is that just because two programs have an "event model" doesn't mean that they're talking about the same event loop. I could write a program that handles Windows events (i.e. messages, like WM_CLOSE), while having my own event loop, such as the code that Nick posted some time ago using a C++ STL priority queue to manage a list of timed events.

Quote:
Micro$oft, which has a huge corner of the market, is generally in a better position to force people to make the switch by simply not making things backwards compatible.

Actually I think that Microsoft is generally pretty good about keeping things backwards compatible, at least from the user's perspective. For instance Nick has been able to continue compiling MUSHclient in VC++ 6 and it has been working on very many versions of Windows and still does today, despite his IDE being now at least 5 years old.

When they remove backwards compatibility it tends to be more from the developer's perspective, in that they really, really want you to use the newer technologies and make it harder to use the older stuff in the more recent IDEs. Still, it's possible; after all it's just code (with header files) being compiled against libraries, and if you have said header files and libraries then you're fine...

Quote:
What does this have to do with anything on this board?

Well, he started saying something about it, and I think I prompted a lengthier explanation by saying "I have no idea what you just said", because I didn't understand it due to not having any context and the initial statement coming out of the blue. In any case if Shadowfyr wrote more it's probably because of me.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Nick Gammon Australia (23,120 posts) Bio Forum Administrator

Date

Reply #55 on Sat 10 Mar 2007 08:32 PM (UTC)

Message

Discussion continued at:

http://www.gammon.com.au/forum/?id=7698

The topic was wandering off text editors.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by Isthiriel (113 posts) Bio

Date

Reply #56 on Fri 16 Mar 2007 11:07 AM (UTC)

Amended on Fri 16 Mar 2007 11:11 AM (UTC) by Isthiriel

Message


class textedit(Frame):
	global Root 
	Root = Tk() 
	global Sb
	Sb = Scrollbar(Root)
	global Tx
	Tx = Text(Root)

Does the global keyword make sense in this context?

If you make these class variables you can only ever have one text editor window open. If they are instance variables the limitation becomes OS/hardware.


	def __init__(self, parent=None):

		try:
			Tx.config(font=('Bitstream Vera Sans Mono', 9, 'normal'))
		except:
			Tx.config(font=('courier', 9, 'normal'))

For me (Python 2.5), attempting to set an invalid font fails without an exception being thrown. The font defaults to the system font, I think. In my case that is Arial. The tkFont module has families() which produces a tuple of all the available font families.


		Tx.focus_set()
		Sb.pack(side=RIGHT, fill=Y)
		Tx.pack(side=LEFT, fill=Y)
		Sb.config(command=Tx.yview)
		Tx.config(yscrollcommand=Sb.set)

The ScrolledText module is available to simplify this.


		menubar = Menu(Root)
		File = Menu(menubar, tearoff=0)
		menubar.add_cascade(label="File", menu=File)
		File.add_command(label="Save", command=textedit.save(self))

Major Bug!

Firstly, you want the instance-method "save" not the class-method "save" ie. self.save() rather than textedit.save()

Secondly, and more importantly, you are calling textedit.save instead of passing it as a callback!


		File.add_command(label="Quit", command=Root.destroy)


		Root.config(menu=menubar)
		Root.title("MUSHComposer  -- "  + str(world.WorldName))
		
	def save(self):
		filename = asksaveasfilename()
	   	if filename:
			text = Tx.gettext()                      
			open(filename, 'w').write(text) 
			al_norm(text)

What is al_norm supposed to do?

I took a shot at trying to produce what you wanted. I've never used Tkinter (my preferred gui library is wxPython :) ). This is what I came up with:


# Rakon's MUSHClient/WSH/Python/Tkinter Easy Text Editor
# Bugfixed by Isthiriel

# Additional Tkinter code lifted from "An Introduction to Tkinter" by Fredrik Lundh.
# http://www.pythonware.com/library/tkinter/introduction/

from Tkinter import *
import tkFileDialog
import ScrolledText
import tkFont

import thread
# Need to fork() the editor window's event loop as
# attempting to call edit() twice without this causes
# MUSHClient and the editor window to lock up.

class TextEditor(Frame):
	def __init__(self, master = None):
		Frame.__init__(self, master)
		self.pack()
		self.master = master
		master.title('MUSHComposer')
		self.CreateMenu()
		self.CreateTextBox()
		
	def CreateMenu(self):
		menu = Menu(self.master)
		self.master.config(menu = menu)
		filemenu = Menu(menu, tearoff = 0)
		menu.add_cascade(label = 'File', menu = filemenu)
		filemenu.add_command(label = 'Save', command = self.OnSave)
		filemenu.add_command(label = 'Quit', command = self.master.destroy)

	def CreateTextBox(self):
		tx = ScrolledText.ScrolledText(master = self)
		if 'Bitstream Vera Sans Mono' in tkFont.families():
			tx.config(font = ('Bitstream Vera Sans Mono', 9, 'normal'))
		else:
			tx.config(font = ('Courier', 9, 'normal'))
		# additional configuration stuff here
		tx.pack(side = LEFT, fill = Y)
		tx.focus_set()
		self.tx = tx

	def OnSave(self):
		fn = tkFileDialog.asksaveasfilename()
		if not fn:
			return
		tx = self.tx.get("0.0", END)
		fp = open(fn, 'w')
		fp.write(tx)
		fp.close()

def edit():
	app = TextEditor(master = Tk())
	thread.start_new_thread(app.mainloop, ())

It seems to work, though resizing-larger doesn't. Probably a default max-size on a frame somewhere.

Top

Posted by

Rakon USA (123 posts) Bio

Date

Reply #57 on Wed 28 Mar 2007 05:11 PM (UTC)

Message

That works almost completly perfect to as what I wanted, thank you!

Certain issues...

Any attempt to send the data, or any command, to MUSHclient, crashes mushclient.

The 'focus_set()' for some reason still doesn't work, as MUSH retains the focus when edit() is run.

Any ideas on how to get this working?? Most of all the first issue, sending the textfield, and commands back to mushclient without crashing.

Thanks!
-Rakon

Yes, I am a criminal.
My crime is that of curiosity.
My crime is that of judging people by what they say and think, not what they look like.
My crime is that of outsmarting you, something that you will never forgive me for.

Top

Posted by

Isthiriel (113 posts) Bio

Date

Reply #58 on Fri 30 Mar 2007 08:32 AM (UTC)

Message

Quote:
Any attempt to send the data, or any command, to MUSHclient, crashes mushclient.

In fact any attempt to reference the world global will crash MUSHclient (outside of the original thread).

I'm not sure if this can be worked around. I think the problem is the world variable is a COM object being provided by MUSHclient to the WSH that actually fires the python interpreter, and because we launch a new thread to handle events in our new window, the WSH thinks its job is done and dismantles the environment while our event thread is still running so attempting to access the (now free'd) variable causes a segfault.

Interestingly, putting a self.world = world in the Frame's __init__ will cause a world.Note to work, and then crash :D

As far as I can see you have a choice between not launching the new thread, keeping access to the world variable and preventing MUSHclient from handling events, or launching the new thread, losing the world variable and handling events correctly :(

On the other hand, it might be possible to attack the problem from the other direction, using pywin32 or something to get a new world object from MUSHclient? I'd have to leave it to Nick at this point as I don't know enough about MUSHclient internals to hazard a guess :(

Quote:
The 'focus_set()' for some reason still doesn't work, as MUSH retains the focus when edit() is run.

The focus_set() is for the text box inside the Tk window to get the focus for the Tk window. It works in that context. It isn't intended to raise the Tk window.

There is a lift() method in Tkinter for top-level windows that should raise the window... however I can't seem to get it to work :( Part of my problem may be that, for me, the edit window appears on top as the active window when the function runs anyway. (So I've been testing with the lower() function that is supposed to send-to-back.)

Top

Posted by

Nick Gammon Australia (23,120 posts) Bio Forum Administrator

Date

Reply #59 on Fri 30 Mar 2007 09:35 AM (UTC)

Message

Quote:

Any attempt to send the data, or any command, to MUSHclient, crashes mushclient.

I am inclined to agree with the previous poster on this. Strictly speaking, MUSHclient hasn't crashed, the script engine, possibly calling an invalid COM object, has crashed. Since the whole thing is running as a single application (albeit with multiple threads), the operating system will report that MUSHclient has crashed.

It is really outside the control of MUSHclient, once execution has passed to a script DLL, to stay stable, if the scripting DLL does things that cause the overall application to crash.

I also agree that starting a different thread may be the problem. I can't say for sure that MUSHclient, or the script interface, is thread safe.

I think the whole idea of making a GUI editor, inside MUSHclient, using the scripting interface, is pushing the intended use of scripts to the very boundaries, or possibly beyond, for what they were intended.

As I mentioned in another thread, I can't see how things like events (eg. clicking in a scripted GUI window) will be successfully handled.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

159,294 views.

This is page 4, subject is 5 pages long: 1 2 3 4 5

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top