Zugg Software :: View topic

Posted: Mon Apr 23, 2007 12:55 am

Wow, OK. Tomorrow I'll put together a small test download to see if we can track this down. It *must* be some change between 1.26 and 1.27+, but according to my version control, I've already reverted that code. So I need to come up with a simple test program to help narrow down the problem. It sure would be nice if I could reproduce it and test it myself, but I'm going to have to rely on you guys to download some tests and report the results.

Oh, I thought of another test you can already try: Go into the Database module and find an edit box and give it a try. The Database module doesn't use the DevExpress controls...they use the built-in Delphi controls (which are very simple wrappers around the Windows edit box). If the Database module works, then that will narrow the problem down to the DevExpress library.

Posted: Mon Apr 23, 2007 1:00 am

The database is working for me.

Posted: Mon Apr 23, 2007 8:40 am

Yep... DB text boxes are fine.

Posted: Mon Apr 23, 2007 7:26 pm

OK, I've uploaded two test programs:

http://www.zuggsoft.com/testedit126.zip
http://www.zuggsoft.com/testedit129.zip

Each of these contains a program called TestEdit.Exe (sorry I didn't make the EXE filename different). When you run each one, it will give the version in the caption of the dialog.

The TestEdit.Exe will show two edit boxes: a normal Dephi Edit box, and a DevExpress edit box. This is the simplest test that I can imagine. No theming or anything.

Run both of these test programs and report the results of each. This should get us started with narrowing down the problem. Thanks for the help!

Posted: Mon Apr 23, 2007 8:39 pm

I get a 404 when I try to download those zips.

Posted: Mon Apr 23, 2007 8:45 pm

Zugg.. The URL's aren't valid. I'm not able to download either file.

Posted: Mon Apr 23, 2007 11:11 pm

Bah...stupid case sensitivity! OK, try them again. With I had read this post earlier in the day :(

Posted: Mon Apr 23, 2007 11:20 pm

Still 404ing...

Posted: Mon Apr 23, 2007 11:51 pm

TestEdit for 126
TestEdit for 129

Posted: Tue Apr 24, 2007 12:05 am

I'm sorry, Zugg... but both textboxes in both versions are working fine, and CMUD 1.29 is still broken.

Posted: Tue Apr 24, 2007 2:46 am

OK, here is the next test: http://www.zuggsoft.com/files/testedit.zip

This adds the OfficeXP blue theme that is used in most of CMUD. This should give the gradient background to the window...the same background as in the #PROMPT window test. Let me know if it still works.

Posted: Tue Apr 24, 2007 2:58 am

Both still working fine.

(Anyone else see this going so far that Zugg'll have added every single CMUD feature into this TestEdit.exe? Lets hope it doesn't break, then we can just use that instead :P)

Posted: Tue Apr 24, 2007 3:06 am

OK, another version. Same link as above: http://www.zuggsoft.com/files/testedit.zip

This is version 1.29b. I have removed the normal Delphi edit box, in case it is interfering. I have added the full theme support from CMUD (although you can't select the theme) to see if that causes the problem.

Let me know. And thanks for the quick turnaround!

Posted: Tue Apr 24, 2007 4:02 am

I tested all versions and they all work fine for me.

Posted: Tue Apr 24, 2007 4:10 am

Hrrrmmm...this is getting annoying. I can't imagine what else to change...it should be working the same as CMUD now. I'll have to sleep on this one.

Posted: Tue Apr 24, 2007 7:02 am

One more version before bed. v1.29c: http://www.zuggsoft.com/files/testedit.zip

This version turns on optimization and uses the FastMM, madExcept, and FastCode stuff that CMUD uses. It's a long shot, but worth a try. Let me know when you get a chance, although I won't read this again till tomorrow (Tuesday...hmm, I guess it's already Tuesday. Well, you know what I mean)

Posted: Tue Apr 24, 2007 2:57 pm

That last version still worked fine for me. I'm not sure of the text fields and forms work in Delphi, but maybe the problem isn't so much the the single text field themselves, but the fact that there are several container and form layers and multiple references in memory.

The look and feel of the problem really reminds of when two screen paint routines are updating the same field or item, and because of minor differences in the coordinates (one frame vs another) the update is off.

Since its affected by typing I would suggest also looking at any keystroke monitoring routines you put in. It occurred with 1.27 which is when the new editor (and as a result some key stroke monitoring) were added.

Sorry it's not sorted yet, but hopefully those ideas help or at least help think in another direction.

Posted: Tue Apr 24, 2007 5:54 pm

That's why I asked people to test the #PROMPT command. The Delphi form design for the Prompt dialog window is the same as what I'm using for the test program...it's very simple with no frames or multiple container layers. When you first run CMUD, none of the stuff in the Package Editor is loaded yet, until the first time you open the package editor. So, none of the stuff for the new editor is even active yet.

I agree that it must be somehow creating two edit boxes and overlapping them somehow. The DevExpress control *does* use a inner "container" edit box, which is why it's more complicated than the normal Delphi edit box. But the test program should have uncovered any problem with the DevExpress control. There must be some complex interaction between something else CMUD is doing.

Actually, the DLL for the editor is loaded into memory at CMUD startup, even though it's not active on any form yet. Maybe the DLL is doing something wierd to intercept Windows messages or something. I'll put the editor in the test program and see what happens.

And remember that I cannot reproduce this on a dozen computers that I have tried (and you have mentioned that it only fails on your work computer, but not the home computer). So, this is something more related to a driver issue I think.

Since I've added about all I can think to the test program, I think I'm going to take Fang's suggestion and start from the other end. I'll start with a version of CMUD and try to start narrowing down the problem there. Look for more test programs soon.

Posted: Tue Apr 24, 2007 6:03 pm

OK, another new version of the text program at: http://www.zuggsoft.com/files/testedit.zip

It's the same version number, but it adds a Scintilla editor component to the bottom of the form. This should test Tech's theory that the editor might be interferring. Let me know if it still works.

Posted: Tue Apr 24, 2007 6:27 pm

And just in case the previous test works (but please test it to let me know), I have created another test that starts with CMUD and strips stuff out (like Fang joked about). It has a new filename: http://www.zuggsoft.com/files/testcmud.zip

It contains a testcmud.exe file, which you should place into the same directory as your existing CMUD.EXE file. You'll see the CMUD splash screen, and then you'll see the test edit box window. You won't get any of the other normal CMUD stuff (no Sessions, no main window, etc). This has the same compression, and also has the copy protection wrapper around it, so you'll need to have a normal CMUD license already active on your computer.

If this testcmud.exe doesn't fail, then I'm really stumped. But let me know the result of both tests. Thanks!

Posted: Tue Apr 24, 2007 6:33 pm

That last testedit doesn't fail. TestCMUD does fail.

Posted: Tue Apr 24, 2007 6:35 pm

OK, thanks...that's *some* progress. That means that somewhere in one of the unit initializations, the edit boxes are getting screwed up. More tests in an hour or so (having lunch now).

Posted: Tue Apr 24, 2007 7:15 pm

TestEdit works for me. Trying TestCMUD now.

[Edit] Test CMUD fails for me as well.

Posted: Tue Apr 24, 2007 8:18 pm

OK, next test: v2.0 http://www.zuggsoft.com/files/testcmud.zip

This removes the exe file compression. Hopefully this will still fail, but let me know.

Posted: Tue Apr 24, 2007 9:49 pm

I'm getting an error with this new file. It's complaining about FastMM_FullDebugMode.dll was not found.