[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Python
. . -> [Subject]  Easy Text editor?
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Easy Text editor?
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please)
Maximum of 6000 characters. Text only please, no HTML.
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...


Subject review (reverse sequence)

Pages: 1 2  3  4  5  

Posted by Isthiriel   (111 posts)  [Biography] bio
Date Fri 30 Mar 2007 06:04 PM (UTC)  quote  ]

Amended on Sat 31 Mar 2007 08:03 AM (UTC) by Isthiriel

Message
I spent some time thinking of a lot of very complicated ways that would almost-but-not-quite work until I asked myself what I was trying to acheive.

The problem is access to the world variable from a thread that hasn't been spawned by MUSHclient/WSH.

The simple answer: defer the execution of code requiring world from the Tk event thread to a WSH thread!

Isthiriel's Workarounds and Hacks'R'Us
or the uses and abuses of Python's exec statement.

Add to TextEditor.__init__:

		self._queue = []
		self._qlock = thread.allocate_lock()


And the following functions to TextEditor:

	def queue(self, code, locals = {}):
		#with self._qlock:
		self._qlock.acquire()
		self._queue.append((code, locals))
		self._qlock.release()

	def poll(self):
		#with self._qlock:
		self._qlock.acquire()
		while len(self._queue):
			code, locals = self._queue.pop(0)
			exec code in globals(), locals
		self._qlock.release()

(The with keyword is supposed to obviate the .acquire()/.release() calls as of Python 2.5. Supposed to.)

And replace the current global edit() function with:

apps = []

def edit():
	global apps
	apps.append(TextEditor(master = Tk()))
	thread.start_new_thread(apps[-1].mainloop, ())

def poll():
	global apps
	for app in apps:
		app.poll()


And the final step:
Add a timer to your world that fires every 0.1 seconds (or 0.2 seconds or whenever you feel like it really -- remember this is limited by the global timer-granularity preference) and calls the "poll" function.

Ok, now if we need to call a function that uses world we can defer it by quoting it and passing it as the parameter to queue().

For example, if we add the following to CreateMenu():

		filemenu.add_command(label = 'Send', command = self.OnSend)


And then add the OnSend function to TextEditor:

	def OnSend(self):
		tx = self.tx.get("0.0", END)
		self.queue("world.Send(tx)", locals())	    


The File menu now has a "Send" option that dumps the contents of the text box to the mud :)

This seems to work with no great disadvantages. The biggest problems are (1) the delay between clicking something in the editor and the timer firing in MUSHclient to actually handle the code and (2) there is a rumoured memory leak somewhere in the binding between MUSHclient, WSH and Python which is supposedly around 4KB per script call. So you want the timer rate to be as small as possible while keeping the potential leak manageable (0.1 seconds between calls => 40KB/sec => 2.5MB/min => 150MB/hr).

Oh, and as it stands any code still in the queue when the editor window is closed, disappears. (This could be fixed fairly easily.)

PS. Recompiling the script file while an editor window is open makes BAD THINGS happen.

PPS. Just checked the memory leak and with the timer set to 0.1 sec it's leaking about 5MB/min, so on a box with 512MB and a session time around 3-4 hours it's not practical to have a timer interval < 1 sec :(

PPPS. If you have an error in your script when you recompile, the timer will cause you to get a lot of "Could not find poll()" errors. For this reason the first five and last five lines of my .pys are:

vTimer = 'ScrStartup_TimersEnabled'
if None == world.GetVariable(vTimer):
	world.SetVariable(vTimer, world.GetOption('enable_timers'))
	world.SetOption('enable_timers', 0)
	world.DoCommand('Save')

if None != world.GetVariable(vTimer):
	world.SetOption('enable_timers', world.GetVariable(vTimer))
	world.DeleteVariable(vTimer)
	world.DoCommand('Save')
world.ColourNote('white', 'black', "Script Compiled")

This code disables the timers (and remembers their enabled/disabled state) for the duration of the compile (not a bad thing) and if there is an exception or a parse error the timers stay off while the compilation aborts. The next time you recompile (with hopefully fixed code) the timers are reenabled (or not, if they were disabled before you started the first recompile).
[Go to top] top

Posted by Nick Gammon   Australia  (19,673 posts)  [Biography] bio   Forum Administrator
Date Fri 30 Mar 2007 09:35 AM (UTC)  quote  ]
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
[Go to top] top

Posted by Isthiriel   (111 posts)  [Biography] bio
Date Fri 30 Mar 2007 08:32 AM (UTC)  quote  ]
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.)
[Go to top] top

Posted by Rakon   USA  (123 posts)  [Biography] bio
Date Wed 28 Mar 2007 05:11 PM (UTC)  quote  ]
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.
[Go to top] top

Posted by Isthiriel   (111 posts)  [Biography] bio
Date Fri 16 Mar 2007 11:07 AM (UTC)  quote  ]

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.
[Go to top] top

Posted by Nick Gammon   Australia  (19,673 posts)  [Biography] bio   Forum Administrator
Date Sat 10 Mar 2007 08:32 PM (UTC)  quote  ]
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
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Thu 01 Mar 2007 11:05 PM (UTC)  quote  ]
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
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Thu 01 Mar 2007 09:52 PM (UTC)  quote  ]
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.
[Go to top] top

Posted by Nick Gammon   Australia  (19,673 posts)  [Biography] bio   Forum Administrator
Date Thu 01 Mar 2007 08:00 PM (UTC)  quote  ]
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
[Go to top] top

Posted by Shadowfyr   USA  (1,776 posts)  [Biography] bio
Date Thu 01 Mar 2007 07:52 PM (UTC)  quote  ]
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.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top

Posted by Shadowfyr   USA  (1,776 posts)  [Biography] bio
Date Thu 01 Mar 2007 07:46 PM (UTC)  quote  ]
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.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top

Posted by Nick Gammon   Australia  (19,673 posts)  [Biography] bio   Forum Administrator
Date Thu 01 Mar 2007 07:39 PM (UTC)  quote  ]
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
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Thu 01 Mar 2007 07:58 AM (UTC)  quote  ]
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
[Go to top] top

Posted by Shadowfyr   USA  (1,776 posts)  [Biography] bio
Date Thu 01 Mar 2007 07:38 AM (UTC)  quote  ]
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...

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Thu 01 Mar 2007 12:15 AM (UTC)  quote  ]
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
[Go to top] 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.


23,204 views.

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

It is now over 60 days since the last post. This thread is closed.   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Web site powered by FutureQuest.Net]