PlanetSquires Forums

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: ? on COPYMEMORY  (Read 563 times)

Paul D. Elliott

  • Guest
? on COPYMEMORY
« on: January 10, 2005, 06:37:32 PM »

Back in December, I updated my PB INC files with the 11/3/2004 version
but didn't think to do any testing at the time. Today I tried to compile and
got a message about missing declare for COPYMEMORY. This happens if
I have the IncLean option checked in the Environment configuration. If I
uncheck that option ( so that it includes the whole set of INCs ) then the
compile works.

Did I miss something in the v1.10 update or was something changed that
is messing up IncLean? The text files with the PB update don't mention
any changes around COPYMEMORY.

Thanks.
Logged

TechSupport

  • Guest
? on COPYMEMORY
« Reply #1 on: January 10, 2005, 07:20:59 PM »

I just tried it here with a test project and it worked perfectly with the IncLean setting enabled. I then download the latest WinAPI declares from PB and it also worked okay. I even tried it with the %USEMACROS enabled and disabled.

:?

Is there anything else on the source line with your call to CopyMemory that may be fooling Borje's IncLean during its parsing?????
Logged

Paul D. Elliott

  • Guest
? on COPYMEMORY
« Reply #2 on: January 10, 2005, 07:27:41 PM »

It's not my code. It's yours. probably something to do with TabControl
and child forms ( CopyMemory ff_child, ff, SizeOf(@ff) ). I can't see
anything strange around that area.
Logged

TechSupport

  • Guest
? on COPYMEMORY
« Reply #3 on: January 10, 2005, 07:42:53 PM »

hmmm.... that's odd. I'll check my code generator to see why I would generate a CopyMemory. I don't think that the TabControl sample that ships with FireFly uses CopyMemory in its generated code.

I will double check my source and report back here......
Logged

Paul D. Elliott

  • Guest
? on COPYMEMORY
« Reply #4 on: January 10, 2005, 07:50:36 PM »

sorry, I didn't look close enough. It's in the combobox create. normally
my problems turn up because of something with the tabcontrol.
Logged

TechSupport

  • Guest
? on COPYMEMORY
« Reply #5 on: January 10, 2005, 09:56:53 PM »

Yeah, it is in the combobox create. I made a sample project with several comboboxes and the error does popup here.

I used Borje's Inclean standalone program on the FireFly generated files and it did pick up the CopyMemory correctly. So, there appears to be some problem with the way that FireFly is interacting with the generated source from Borje's program. I will run a few more tests to isolate the problem.
Logged

TechSupport

  • Guest
? on COPYMEMORY
« Reply #6 on: January 10, 2005, 11:32:44 PM »

hmmmm.... funny thing is that it works correctly on one of my computers but not on the other. Strange. I'll dig further to see what is going on. In the meantime, continue to compile your project without the InClean activated.
Logged

Paul D. Elliott

  • Guest
? on COPYMEMORY
« Reply #7 on: January 13, 2005, 11:15:33 AM »

Paul,

Someone else found the problem & solution over on the PB forums.
There are TAB characters in the latest set of INCs from PB and the
IncLean programs have a problem with them.

I just loaded win32api.inc into a text editor and made a small change
and saved it. Turned on the IncLean option in FF and it works.

Could we get an option in JellyFish to convert TABs to spaces in the whole
file ( not just as we type )?
Logged

TechSupport

  • Guest
? on COPYMEMORY
« Reply #8 on: January 13, 2005, 12:47:26 PM »

Hi Paul,

Thanks for the update - I would have spent a VERY LONG TIME trying to figure that out.

All I need to do is filter out the Tabs prior to sending the FireFly generated source to Inclean. Simple. Fix will be in v1.11.
Logged

Paul D. Elliott

  • Guest
? on COPYMEMORY
« Reply #9 on: January 13, 2005, 01:43:11 PM »

Now I'm getting confused. Do you process all the INC files into 1 and send
it  and your BAS file thru the IncLean DLL  or does the IncLean DLL  
process the original INC files based on the BAS file you create?  If it is the
latter then the DLL needs fixing.

just trying to be helpful ( at times ).
Logged

TechSupport

  • Guest
? on COPYMEMORY
« Reply #10 on: January 13, 2005, 04:00:44 PM »

:oops:  Right you are. I guess that I spoke to quick. You're right. I do not process the PB includes other than add them to the main generated BAS file via #Include statements.

Borje posted in the PB forum that he would make the changes to Inclean. I
will distribute the new DLL as soon as I get it.
Logged

Paul D. Elliott

  • Guest
? on COPYMEMORY
« Reply #11 on: January 14, 2005, 11:45:14 AM »

I just got the DLL from his site and it does work. But I have a question.
Why is this version TWICE the size of the previous one? Did you run
some compaction program on it or did he add a BLOAT command?
Thought I'd ask here first in case you had done something special.

Sometimes it bothers me when programs drastically change size
for no apparent reason. I know it is probably minor but can't find
something major to worry about.
Logged

Roger Garstang

  • Guest
? on COPYMEMORY
« Reply #12 on: January 14, 2005, 12:37:41 PM »

Opening FF's with Resource Hacker states it is compressed, and it is the same size as the zipped version which is about the same way the compressor would have compressed it, so I'd say Paul compressed it.  I wonder how many times i can say compressed in one post.  I guess I could have compressed my post, but it wouldn't be as much fun compressed.
Logged

TechSupport

  • Guest
? on COPYMEMORY
« Reply #13 on: January 14, 2005, 01:15:50 PM »

Right you are.... looks like at some point over the course of developing FireFly that I must have compressed the DLL. Why? I don't know. Maybe just to see how much it would shrink. No practical reason because it is shipped via a zip file so I would get the smaller distribution size anyway.

Sometimes I do strange things for no apparant reason. :mrgreen:
Logged

Paul D. Elliott

  • Guest
? on COPYMEMORY
« Reply #14 on: January 14, 2005, 01:46:17 PM »

Okay, I was just curious. I have had some compiles in the past go very
wrong when debug code ( or sub-routines got overwritten with completely
wrong sources or some other very stupid programmer error )  got put
into production.
Logged