|
|
Post by roberto on Jan 5, 2021 18:20:14 GMT -5
Just for fun I am programming in LB some visuals of mathematics.
For instance, in a graphicbox I draw a cube using twelve lines. The angular points are indicated A, B, C, etc. To show those indications in a graphicbox I use the usual cluster of subs and functions for transparant text (SetBkMode, GetDC and ReleaseDC). So foar so good.
Then I cut a part of the cube at one of the angular points, leaving a triangle plane on the cube.
To show that triangle plane on the cube I would like to 'floodfill' it. And to program 'floodfill' in that triangle I need another cluster of usual subs and functions (ExtFloodFill, GetDC, ReleaseDC, and FloodFill).
As expected this combination of clusters will not run.
The one GetDC uses (hw) and the other (hWnd). The one ReleaseDC is a 'sub' and the other a 'function'.
Whatever I change, switch, rearrange, rename (handle, hw, hDC, HDC, hWnd, Hwin) I cannot get the program working. When I floodfill (mouse-event) I am thrown out of Liberty Basic with the notification 'Runtime Error: Dynamic Link Library call error (see error.log for more information)'.
Is there anyone who can read such error.logs? Because I cannot.
|
|
|
|
Post by Chris Iverson on Jan 5, 2021 19:21:46 GMT -5
You can try to paste the contents of the error log, or at least the most recent error report.
In my experience, though, I've only gotten "Dynamic Link Library call error" when I tried to call a function that didn't exist. Are you sure that you've got the name of the function in the DLL right?
The names are case sensitive, and there are times when the raw function names in the DLL are different from what's in any documentation, due to things like overloading and Unicode support. The raw function names in the DLL is what you would need to call the function.
If you want an idea of which function call is failing, try single-stepping the program through the debugger, or turning on the mainwin and PRINTing something out right before each DLL call.
If you can, do you have a code example you can share that demonstrates the issue?
|
|
|
|
Post by roberto on Jan 6, 2021 0:56:13 GMT -5
Thank you very much for such a quick reply. I hereby send you part of the error log file.
I have to create another reply for sending you the program.
Attachments:error log 06-01-21.txt (2.27 KB)
|
|
|
|
Post by roberto on Jan 6, 2021 0:57:37 GMT -5
|
|
|
|
Post by Rod on Jan 6, 2021 3:50:26 GMT -5
The flood fill api and most graphic api calls cannot deal with floats. So use int() on graphic coordinates x and y. You should get the DC at the start of the program and release only on exit. You can either pass the hDC value to subs or functions or make it global and just use it in subs and functions. Interesting use of checkbox to replace buttons.
|
|
|
|
Post by tsh73 on Jan 6, 2021 9:34:25 GMT -5
It looks like for filling you should pass starting point. Likely mouse position.
So you should change
OK = ExtFloodFill(hDC,x,y,Color)
to
OK = ExtFloodFill(hDC,MouseX,MouseY,Color)
|
|
|
|
Post by roberto on Jan 9, 2021 10:23:15 GMT -5
Thank you both for considering my attempts creating a small program. It is good to know that problems are understood and that thoughts of possible solutions are presented.
In the meantime I rearranged some lines to [flood] (the rightButtonDown-event) and in accordance with the advice from Rod I turned my x and y to int()s now.
And as tsh73 suggested I changed the mouse positions from x and y to MouseX and MouseY too. They work miracles now, but respond on any pixel in the cube. So I will try to find a logical common square in every plane to prevent floodfilling other not-intended planes of the cube.
And yes, as there are many figures to be subject of the program I prefer to use a couple of checkboxes with a double function instead of quite a lot of buttons with a singular effect.
Anyway, I will be pleased to meet you next time.
|
|
|
|
Post by Rod on Jan 10, 2021 3:16:58 GMT -5
|
|
