On Thu, 2002-09-19 at 09:03, Tony Maro wrote: > > Anyway, it's fairly consistently happening (during any 4 hours of > programming) but I can't tell you any one thing to do to trigger it.

I have downloaded your program. I found some gtk warnings and some other small issues, which I have fixed. But still no buggy renaming. Your hints:

The .lrs file? You have edited the .lrs file manually? Do you mean the .lfm file?

The more controls on a form the more likely it is to happen.

Hmm ...

Adding controls and then drag-sizing and drag-positioning seems to trigger it, but I'm not sure.

Yes, there is a bug in drag moving, but I'm not sure if this results in renaming components.

If you delete the affected control, the next control that gets shifted into that spot is likely to corrupt almost immediately.

Hmm ...

I constantly save all and build all when programming, that may affect it.

This probably reduces the errors.

It doesn't seem to affect the currently open copy in the editor, but it DOES affect the built app and the next time you open the editor it will throw errors.

Makes sense.

It is NOT because I have a bitmap or other graphic stored in the resource. In fact I even took out all bitbtn's when you guys started working on the streaming code for bitmaps.

ok

I actually think the editor has detected the changes before because once or twice when I've had the editor open it has flagged that a file changed while I had it open even though I hadn't changed anything.

What files were flagged and were they opened?

The corruption seems to start in the .lrs file but will ultimately be mirrored in the .lfm file as well (perhaps the next time you open the project?)

Now that is strange. The .lfm file and the .lrs file are always saved together. And the .lfm file is created after the .lrs file. So, the error should always be in both.

Tricky. I have not yet seen it. Maybe I should add some consistency checks for the designer so you can find the bugs earlier ...

:)

Mattias

At work today I grabbed the latest CVS of Lazarus. Before that I was still running the patch that Andrew sent me.

My pop-down calendar edit control now displays a blank box. The same sources compiled on my lazarus at home (from about a week ago) work fine. I haven't changed the code - only Lazarus has changed.

I'm assuming it has something to do with the linking of the TCalendar component to a form created at runtime... my form appears, but the TCalendar never does.

Or perhaps it broke the TCalendar component... I'm not sure.

-Tony

<<winmail.dat>>

nope.. looks like Panel & subcontrols aren't working quite right currently.. just disable the prettiying panel(as it doesn't really affect functionality anyway) and set the calendar's parent to the form.. I have no idea what changed in CVS that caused this because I have several forms that use panels etc without issue..but.

Andrew

_________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

I'll see about updating the sndfile.pp file tonight or tomorrow.

Michael.

-----Original Message-----
From: Mattias Gaertner

The .lrs file? You have edited the .lrs file manually? Do you mean the .lfm file?

Only to fix the errors. For instance just now it corrupted a button called BtnDepositOk.

While I still had Lazarus open, everything was fine in the environment, but when I built the project it would crash and the form resource reports unknown property 'TABSTA'. I opened unitmain.lrs and on line 86 I see:

+'ORS'#11#5'aktop'#6'akleft'#0#7'CAPTION'#6#2'OK'#7'TABSTTA'#8#7'VISIBLE'#8#7

You can see the TABSTTA in the middle there... which is wrong. The amount of characters is correct, but the text has been corrupted.

Opening the unitmain.lfm file at the same time shows everything is fine in it...

Close Lazarus, saving changes. Now here's what is in the unitmain.lfm starting at line 326:

object BtnDepositOK: TBUTTON
ANCHORS = [aktop, akleft]
CAPTION = 'OK'
TABSTTA = False
VISIBLE = False
ONCLICK = BtnDepositOkCLICK
LEFT = 477
HEIGHT = 15
TOP = 104
WIDTH = 75
end

Again, the TABSTTA has appeared. Sometimes it's the name of the object that's corrupted, sometimes another property. Always the NUMBER of characters is the same, they are just wrong.

If I go in and fix both files to read TABSTOP everything is peachy again.

> The more controls on a form the more likely it is to happen. Hmm ...

Actually, I think it always happens on or around line 86 of the .lrs file. I've seen it happen in a property that wrapped from line 85 to 86 and in the middle of 86. I wasn't watching close to begin with, but I'm pretty sure it's always right around there.

Yes, there is a bug in drag moving, but I'm not sure if this results in renaming components.

This time the only thing I did was edit properties of buttons to not be visible. It does only seem to happen when I work with the form designer, though. If all I do is change code, it doesn't seem to happen.

I don't recall.. it's only happened twice and it was yesterday. Could be something else entirely because it doesn't happen every time, that's for sure.

Is the .lrs file saved by itself when only building a project - getting it ready for the linker or something? Or is the .lfm file modified when you open a project to make it sync with the lrs? These seem like possibly what's happening... Sooner or later the .lfm has the error too, but not always immediately.

Thanks for the help...

-Tony

<<winmail.dat>>

FYI this has happened to me on occasion.. but usually in a file grown big on account of bitmaps.. so its not really periodic for me..perhaps it has something to do with a large file, or a large property value(aka a large String list)..

Andrew

_________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

Thanks for the link.

I downloaded libsndfile, compiled and installed it. When I attempt to use it I get errors when linking. I verified the libsndfile files are in a directory listed in ld.so.conf and I ran ldconfig and even rebooted... no such luck.

Anyone have experience with this? I'm ignorant of linkers and libraries...

Sorry - didn't even know I could get more error info until I dug deeper:

sfplay.o in function '_PLAYFILE$STRING':
sfplay.o(.text+0z132): undefined reference to 'sf_open_read' sfplay.pp(107) Error: Error while linking

Can you send me an example where this likely happens, so I can track and fix it?

Mattias

umm this is wierd.. I can ALWAYS reproduce this problem.. I was fiddling with his form. and

a. deleted his "Edit" button..
b deleted his open dialog
c.deleted his "cancel" button
d moved his "new "button over a bit
e. saved all
f. closed lazarus
g. reopened

and on reopen I get the error.. every single time. I can delete dif. components.. move a dif control it always happens for me..

but!! if I remove the ImgWithdrawal component.. then I never ever get this problem..

However when I do get error it is always within a few lines of where Tony pointed out so...
is it a problem with TImage? is it a problem with streaming? or maybe both?

Andrew

_________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

Tony Maro wrote

I checked into playsound, but it appears to be just a windows header. Any Linux sound support in the works or already included?

Yes, check the sndfile package (and unit), and the sfplay example.

http://www.freepascal.org/packages/sndfile.html

Michael.

What are the errors ?

Michael.

There was a bug, so that sometimes linker errors were not shown in the IDE messages. Fixed.

Mattias

Mmm... well here's the entire application:
http://members.telocity.com/~tonymaro/cbtrackerbad.tar.gz

It's an older copy (due to corruption I've taken to keeping 3 days worth of backups). This particular copy has a corrupted MainMenu control on main form (name is corrupted). The app still builds, even though procedures reference the incorrect name, but when you fire an event that would use it, it crashes.

The more labels I throw on a form the more likely it is to happen (I tossed some extra on this test download to make it more likely), and it only seems to happen about every 10 - 20 saves maybe. I pruned back my labels last night and started creating several at runtime and it quit corrupting the SaveDialog1 I had, but then it corrupted the component name of one of my popup menus on the form.

Anyway, it's fairly consistently happening (during any 4 hours of programming) but I can't tell you any one thing to do to trigger it.

It appears they changed the functions between versions of sndfile, and I got the wrong one... I've been looking at the sources and it's no longer sf_open_read but is sf_open and requires and extra parameter.

Tony Maro wrote

Anyway, it's fairly consistently happening (during any 4 hours of programming) but I can't tell you any one thing to do to trigger it.

I've been watching today and here's what I've learned:

It seems to happen at about the same position of the form resource file each time. (around line 86 of the form's lrs file) - I've noticed that VI will place me right near the position of the error every time I open the file to fix it.

The more controls on a form the more likely it is to happen.

Adding controls and then drag-sizing and drag-positioning seems to trigger it, but I'm not sure.

If you delete the affected control, the next control that gets shifted into that spot is likely to corrupt almost immediately.

I constantly save all and build all when programming, that may affect it.

It doesn't seem to affect the currently open copy in the editor, but it DOES affect the built app and the next time you open the editor it will throw errors.

It is NOT because I have a bitmap or other graphic stored in the resource. In fact I even took out all bitbtn's when you guys started working on the streaming code for bitmaps.

I actually think the editor has detected the changes before because once or twice when I've had the editor open it has flagged that a file changed while I had it open even though I hadn't changed anything.

The corruption seems to start in the .lrs file but will ultimately be mirrored in the .lfm file as well (perhaps the next time you open the project?)

I hope with my help we can pin this down pretty quick. The larger my app gets the worse the problem seems. I'm about 3-4 working days away from my first functional release of the checkbook balancing software, but if this gets any worse I won't be able to finish until it's resolved.

BTW: I just want to congratulate the whole development team on a job well done! For me to have no Linux programming experience and go from downloading FPC and Lazarus for the first time to a viable finished product such as this in under 3 weeks is just amazing, even with my Delphi 4 experience. I expect to have all the bells and whistles on it (such as category management, scheduled recurring transactions and balance forecast graph) within another 2-3 weeks, and multiple account management and online banking imports within about 5-8 weeks.

-Tony

Actually, I think it always happens on or around line 86 of the .lrs file. I've seen it happen in a property that wrapped from line 85 to 86 and in the middle of 86. I wasn't watching close to begin with, but I'm pretty sure it's always right around there.

By the way - I had another corruption at the same time on line 88 and immediately after another on 86 with the TABSTTA "property" again.

<<winmail.dat>>

Lazarus periodically insists on changing my main form SaveDialog1 to have a property titled "FILTEFILTER = 0" instead of "FILTERINDEX = 0" regardless of what I do. (or another control with similar corruption)

So far I've been able to fix the files by hand using good old fashioned VI...

Is anyone else experiencing this consistantly?

I checked into playsound, but it appears to be just a windows header.

Any Linux sound support in the works or already included?

Thanks,

Tony

Mattias Gaertner wrote

Marc, can you apply it and build a new compiler plz?

They are on their way.

Marc

I can live without a panel. No problem there.

But, one more thing...

(seems like the more components I have the worse it gets...)

I just dumped the whole panel at the top idea and dropped labels directly on the form, moving down the transaction display.

Weird shee-it happend notebook control at the bottom duplicates all the tabs and crashes if you click a tab. The menu and other controls don't appear. Delete the labels from the form and everything goes back to normal.

My latest version of the application is at:
http://members.telocity.com/~tonymaro/cbtracker.tar.gz

I can create the same labels at runtime without a problem.

-Tony

Fixed.

Michael.

I was just noticing that the form resource appears streamed from a buffer of 4096 bytes. (main.pp: dosavefileresources) Are we passing that threshold? I just recompiled Lazarus after bumping that to 8192 and haven't been able to reproduce the problem since (yet...)

That's it.
It is a bug in TBinaryObjectWriter.Write.
Buffer is not adjusted. Here is a fixed version:

procedure TBinaryObjectWriter.Write(const Buffer; Count: LongInt);
var
  CopyNow: LongInt;
  SourceBuf: PChar;
begin
  ;
  while Count > 0 do
  begin
    CopyNow := Count;
    if CopyNow > FBufSize - FBufPos then
      CopyNow := FBufSize - FBufPos;
    Move(SourceBuf^, PChar(FBuffer)[FBufPos], CopyNow);
    Dec(Count, CopyNow);
    Inc(FBufPos, CopyNow);
    inc(SourceBuf, CopyNow);
    if FBufPos = FBufSize then
      FlushBuffer;
  end;
end;

I hope someone of the fpc team reads this and fixes it.

Till we got the new compiler packages I have increased the buffersize to 100.000.

Marc, can you apply it and build a new compiler plz?

Mattias

I was just noticing that the form resource appears streamed from a buffer of 4096 bytes. (main.pp: dosavefileresources) Are we passing that threshold?

I just recompiled Lazarus after bumping that to 8192 and haven't been able to reproduce the problem since (yet...)

One more thing... unrelated? Andrew, try dropping a TCheckBox component on that very top panel that has nothing on it. Lazarus immediately crashes.

-Tony

On Thu, 19 Sep 2002 22:10:58 -0500
"Tony Maro" wrote

One more thing... unrelated? Andrew, try dropping a TCheckBox component on that very top panel that has nothing on it. Lazarus immediately crashes.

yep.. completely unrelated.. true GTK widgets have drawing problems on Panels.. Why ? I do not know. I haven't had a chance too look. Some components just don't display, others, specifically TCheckBox and TRadioButton(which are parent drawn, like TGraphicControls) kill the program in question...

Andrew

_________________________________________________________________ Join the world�s largest e-mail service with MSN Hotmail. http://www.hotmail.com

Great.
I have changed the TBinaryObjectWriter buffersize back to 4096.

Mattias