Recent

Author Topic: Unexpected behavior from components created at runtime  (Read 5445 times)

Spoonhorse

  • Full Member
  • ***
  • Posts: 123
Re: Unexpected behavior from components created at runtime
« Reply #30 on: January 12, 2021, 06:02:22 pm »
It's not over. It's. Not. Over.

So, as I said, I reinstalled Lazarus, which made it work. Got a bit of coding done, just like changing and moving a few lines, I must have recompiled it two, three times, then it started breaking again in exactly the same way, always the first time I try to do something to the card array.

So I reinstalled Lazarus again, which, this time, didn't fix the problem. I plan to try reinstalling it two or three more times because what else do I have?

This is terrible. So, unless anyone has any better ideas, this seems to be a unique interaction between my system and Lazarus, so I guess I could try ... buying a new computer? ... or porting the thing to another language.

Does anyone have a less awful idea? Thanks. At my wits' end.

Spoonhorse

  • Full Member
  • ***
  • Posts: 123
Re: Unexpected behavior from components created at runtime
« Reply #31 on: January 12, 2021, 06:14:25 pm »
P.S: Thinking about what MarkMLI said I tried as a quick fix moving the "maketopicbox; makewordbox; updateall14;" bit into FormActivate to see if that would do anything; if the garbage present at FormCreate was the problem that would fix it wouldn't it? No dice.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Unexpected behavior from components created at runtime
« Reply #32 on: January 12, 2021, 06:47:39 pm »
I took some time checking my facts and giving you specific recommendations, based on Jamie's original suggestion. I don't know whether Jamie has any thoughts about your using the FormActivate handler, but if he (or anybody else) has I'd be interested to know them.

If it were a hardware (memory etc.) problem I'd expect the OS to object at some point.

MarkMLl




MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Spoonhorse

  • Full Member
  • ***
  • Posts: 123
Re: Unexpected behavior from components created at runtime
« Reply #33 on: January 12, 2021, 06:54:51 pm »
Yeah, I just tried it that way 'cos it seemed like a quick way to see if that was the problem. Still, I'll try doing it a la post #26 and see what happens.

Spoonhorse

  • Full Member
  • ***
  • Posts: 123
Re: Unexpected behavior from components created at runtime
« Reply #34 on: January 12, 2021, 07:10:02 pm »
Tried the first way suggested. Didn't work. The second looks frankly terrifying, I fear it for I do not understand it. I can give it a go I guess, what's the worst that can ... oh god. The bees, the terrible bees.

Spoonhorse

  • Full Member
  • ***
  • Posts: 123
Re: Unexpected behavior from components created at runtime
« Reply #35 on: January 12, 2021, 07:27:56 pm »
Mark MLI, can you explain that one, the second method in post #26. How does it defer the calls? Where are they made? 'Cos they don't seem to be mentioned in the code. I don't understand, I'm sorry.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Unexpected behavior from components created at runtime
« Reply #36 on: January 12, 2021, 07:40:36 pm »
Mark MLI, can you explain that one, the second method in post #26. How does it defer the calls? Where are they made? 'Cos they don't seem to be mentioned in the code. I don't understand, I'm sorry.

It puts a message onto the message queue to be handled asynchronously. After the message loop starts but before it does anything else of significance, it takes the message off the queue and executes the indicated procedure. Been using it for decades and it's solid.

The premature use of Form1 is what stands out (credit, as I've said before to Jamie). But I'd suggest that you'd also make it easier for yourself if you broke that problematic line at the end of your FormCreate() into four- one statement per line- to limit the risk that the error handler gives you misleading information.

You have in fact got some troublingly-long lines in there- 400 chars and more- but I'd be disappointed if the compiler were getting confused by that.

Anyway, I've wiped the project from my system now since you were so definite that you'd found the problem without trying my suggestions.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Spoonhorse

  • Full Member
  • ***
  • Posts: 123
Re: Unexpected behavior from components created at runtime
« Reply #37 on: January 12, 2021, 08:51:42 pm »
Well, I had fixed it. When I reinstalled it, the durn thing worked. It seemed like the logical thing to try, since it worked on your computer but not mine, and then it did. And then it didn't again.

I'll tried breaking the line up but that didn't change anything. I didn't think it would because after all (a) The error's being reported as coming from in the methods called from within updateall, whatever the first thing I have to do to the card array. So if the first thing is changing the .Left value the screaming comes from TControl.SetLeft. (b) I get the same error if updateall isn't called from FormCreate at all, but is called from somewhere else.

This has tried all our patiences, I can tell. Well, it isn't actually necessary to change my computer or my programming language, but I will have to swallow my pride. The array is small and of fixed size, so I can do without it and have a bunch of separate objects over which I can't iterate. It's a small part of the program, I'll live.

Unless anyone has any better ideas, I'll just go off and write bad inept code, apologizing as I go for sharing this frustrating experience with you.

---

ETA: You could hide a lot of the badness away I guess with something like "function card(i:integer):TLabel" and then a case statement. It would look weird, but then I could iterate over the function. But ... this is what I meant when I said I keep having to circumvent the language.
« Last Edit: January 12, 2021, 09:38:30 pm by Spoonhorse »

 

TinyPortal © 2005-2018