2011/8/16 Andrew Douglas Pitonyak <and...@pitonyak.org>: > Oh my goodness! It is always something small that wastes hours of time.
Yes, it seems like it most of the time… But if the bug you mentioned about that Private acts like Public was fixed, I wouldn't have had this problem, would I? :) Or if I had the magic words ”Option Compatible” involved… ;D Kind regards Johnny Rosenberg ジョニー・ローゼンバーグ > > On 08/15/2011 08:48 AM, Johnny Rosenberg wrote: >> >> Okej, forget this, I solved it. Immediately after I sent this I found >> the problem! All I needed to do to find it out was probably to write >> about it somewhere… >> >> I found the problem when I did a search in all modules for my type >> ”DieStatistics”. I found it in a module called ”Experiment” which is >> Swedish for ”Experiments” in this case. >> >> I did some tests in that module a few days ago, before I declared >> DiceFreq as an array of DieStatistics, so DiceFreq was declared >> globally twice: >> >> Module Experiment: >> Global DiceFreq As DieStatistics >> >> >> Module P: >> Private DiceFreq(1) As DieStatistics >> >> After removing the Experiment ones, everything worked as expected. >> >> Phew, what a relief… I thought I was crazy there for a few minutes…! >> >> >> And I usually don't top post, but in this case I thought it could be >> appropriate, since the text below suddenly became very unimportant. >> >> >> Best regards >> >> Johnny Rosenberg >> ジョニー・ローゼンバーグ >> >> >> 2011/8/15 Johnny Rosenberg<gurus.knu...@gmail.com>: >>> >>> I was editing some code I have, actually a game with dice and stuff, >>> but that doesn't matter, I suppose. >>> >>> So I ran into a problem, and I copied the troubling part of the code >>> to a separate document for test driving. >>> However, the test code runs perfectly, but not within the game of mine! >>> >>> I ran the game on another computer but another version of >>> OpenOffice.org (actually the first computer runs LibreOffice 3.3.3), >>> but the results were exactly the same. >>> >>> Here's the test code. I have a message box after almost every >>> statement so I can see what happens. I added some extra comments in >>> the code. >>> >>> REM ***** BASIC ***** >>> >>> Option Explicit >>> Option Compatible >>> >>> Type DieStatistics >>> Value As Integer >>> Count As Integer >>> End Type >>> >>> ' The variable DiceFreq, declared below this comment, tells us which >>> two die values that are most frequent. For example, if the six dice >>> are 133455, >>> ' DiceFreq will contain: >>> ' DiceFreq(0).Value: 5 (the most common value is 5) >>> ' DiceFreq(0).Count: 2 (2 dice have the value 5) >>> ' DiceFreq(1).Value: 3 (the second most common value is 3 – in this >>> case there are two of both 3 and five, but higher value has priority) >>> ' DiceFreq(1).Count: 2 (2 dice have the value 3) >>> ' This makes it very easy for us to calculate things later, >>> calculations that are not present in this short example though. >>> Private DiceFreq(1) As DieStatistics ' >>> >>> >>> Sub Test0 >>> ' NDice tells us how many there are of each die value. In the above >>> example, NDice(4)=1, since there are 1 die with the value 4. >>> Dim NDice(1 To 6) As Integer, i As Integer >>> >>> ' Here we set the values of NDice for an example where this is >>> known >>> to fail, that is what NDice would contain if the dice were 112345 >>> ' NDice(1)=2, NDice(2)=1 and so on. >>> For i=2 To 5 >>> NDice(i)=1 >>> Next i >>> NDice(1)=2 >>> >>> ' Here's where I calculate the values for DiceFreq by going through >>> NDice from 6 to 1. >>> For i=6 To 1 Step -1 >>> If NDice(i)>DiceFreq(0).Count Then >>> DiceFreq(1).Count=DiceFreq(0).Count >>> DiceFreq(1).Value=DiceFreq(0).Value >>> MsgBox DiceFreq(0).Value& ": "& >>> DiceFreq(0).Count& " st."& Chr(13)& _ >>> DiceFreq(1).Value& ": "& >>> DiceFreq(1).Count& " st." >>> DiceFreq(0).Count=NDice(i) >>> DiceFreq(0).Value=i >>> MsgBox DiceFreq(0).Value& ": "& >>> DiceFreq(0).Count& " st."& Chr(13)& _ >>> DiceFreq(1).Value& ": "& >>> DiceFreq(1).Count& " st." >>> ElseIf NDice(i)>DiceFreq(1).Count Then >>> DiceFreq(1).Count=NDice(i) >>> DiceFreq(1).Value=i >>> MsgBox DiceFreq(0).Value& ": "& >>> DiceFreq(0).Count& " st."& Chr(13)& _ >>> DiceFreq(1).Value& ": "& >>> DiceFreq(1).Count& " st." >>> EndIf >>> Next i >>> MsgBox "Final reults:"& String(2,Chr(13))& DiceFreq(0).Value& >>> ":" >>> & DiceFreq(0).Count& _ >>> " st."& Chr(13)& DiceFreq(1).Value& ": "& DiceFreq(1).Count& >>> " st." >>> End Sub >>> >>> >>> Now, while this works perfectly as a stand-alone subroutine, it >>> doesn't work in the game. What happens in the game is that everytime I >>> change the value of DiceFreq(i).Value or DiceFreq(i).Count, BOTH >>> instances are changed, for example if I set DiceFreq(0).Value to 5, >>> DiceFreq(1).Value is also set to 5 and I just can't figure out why! >>> >>> In the game the corresponding subroutine is called from another >>> module, but I simulated that too in my test, but still it ONLY fails >>> in the game. >>> >>> I can upload my game document (the debug version) somewhere if needed. >>> >>> What on earth could possibly cause this? I'm just out of ideas! >>> >>> Help…? >>> >>> >>> Kind regards >>> >>> Johnny Rosenberg >>> ジョニー・ローゼンバーグ >>> > > -- > Andrew Pitonyak > My Macro Document: http://www.pitonyak.org/AndrewMacro.odt > Info: http://www.pitonyak.org/oo.php > > -- > ----------------------------------------------------------------- > To unsubscribe send email to dev-unsubscr...@api.openoffice.org > For additional commands send email to sy...@api.openoffice.org > with Subject: help > -- ----------------------------------------------------------------- To unsubscribe send email to dev-unsubscr...@api.openoffice.org For additional commands send email to sy...@api.openoffice.org with Subject: help
