For all Firefly users, Egrid32's XML definitions have been
Updated with the new Notifications added.
The New File containing the Newest XML and Declarations file can be downloaded at:
www.SweetHeartGames.com/FF_MODULE_30402.ZIP
Please notice that Firefly Stores the control Properties and Notifications
in each form, so, the new Notification events might be available until you
create a New Egrid32 control in the form (not when you load one made
with the previous XML file). I dont Know if Paul changed this, in that case,
ignore this notice.
If you are a registered user and you still dont have Egrid32 V.3.04.02
you can request it. Please let me know any problems or suggestions you might have.
Thank you.
Elias. :)
Added:
Just uploaded CHM help file 3.04.02 (With intuitive structure)
Quote from: Elias MontoyaJust uploaded CHM help file 3.04.02 (With intuitive structure)
Elias,
Where is the new CHM located ... I can only find the original help file on the website.
Thanks,
Its on Sweetheartgames.com site, here is a direct Link to the newest Help file:
http://www.sweetheartgames.com/EGrid32Pro/EGrid32.chm
Elias :wink:
I finally took a few minutes to play with eGrid32 Pro demo (3.04.00) and FireFly (1.06 B10), but ran into a rather irritating issue, and I picked up something to read instead.. :cry:
The procedure
------------------------------
Start a standard EXE project, and add a grid by either dbl.clicking or click and drag it in wanted position/size.
The problems and fixes
------------------------------
Once the grid is placed, everything but the client area of the form disappears.
Minimizing and restoring FF solves this issue, but the grid does not become visible.
Saving and reopening the project files makes the grid finally come visible.
Sometimes the form is then collapsed to an absolute minimum.
During compilation, FF/PB returns an error (484 - Requires SUB/FUNCTION) on «%EG_GETNEXTUNUSEDINDEX = %WM_USER + 247»
Rem'ing the line off course let's FF/PB compile the project. - for now..
Changing WS_EX_Acceptfiles (among others) makes the whole grid disappear from the form.
Reloading the project makes the grid reappear, but sometimes "squeezes" the form size again.
The demo reminder dialog doesn't always appear when reloading the project.
And it certainly never appears when inserting the grid onto the form. (Something here?)
Tested workarounds
------------------------------
Trying to reproduce the behaviour on a different computer (XP tablet edition)
No difference in behaviour.
Running FF 1.05
No difference in behaviour. (Confirms that the grid is running the show?!)
Trying Twips as measure standard
No difference in behaviour.
Checked line lenght (compile error)
Less than 255 characters.
Using FF 1.05 and latest eGrid.
Start a new exe project
Double click to place a new eGrid control, nothing happened.
Try dragging, nothing happened.
Try double clicking again, nothing happened.
Did this a few times and gave up.
Save the project, open it back up ...
I have 7 eGrids on the form, one for each try I am assuming.
Hello Haakon, I also (like david), tried reproducing the problem and nothing went wrong here. Unfortunately i cant test any further (1.06) because i still dont have FF and my test period has expired. However, ill see what could be wrong.
Maybe download was wrong?? Egrid32 Properties (in Firefly) uses System settings, maybe your sistem settings are set to some colors that makes it look "Invisible"?? maybe...
Remember that (as documented) Egrid32 Requires PB 7.02 or later, if you havent upgraded, it might be causing problems, Upgrade is free.
Im guessing that some files went corrupted, maybe configurations or Egrid Download... also, Egrid32 was designed so that the Demo does not shows the warning mesage during design time in Firefly, but it will show when compiled.
Please e-mail or post more info here so we can spot what is exactly happening.
Elias :)
It seems to me that David was experiencing exactly some of the same behaviour; the grid is not showing up in the form until the project is saved and reloaded.. Thats why he had seven grids (after seven tries) when he reloaded the project.
Anyway, even if I had the system colours totally off standard, it would explain why the grid is not showing when placed on the form, and then appearing as the project is reloaded. Colors arn't altered during that periode.
Compilation goes well with the mentioned line rem'ed, and it looks fine in run-time. (No code for doing anything is added). I'm on PB 7.04, so that's not an issue either. But I fail to see why the PB version should in any way interfere with the grids behaviour in design-time?!
As for the download corruption, it's been downloaded twice, using different download agents (IE, Leechget), on two separate computers. One is rather clean (newly installed Windows) as to how much other things are installed. So everything is doublechecked, and reproduced here.
[Paul, we seem to need a prolonged test periode for Elias.. - would that doable?]
Quote from: Haakon BirkelandIt seems to me that David was experiencing exactly some of the same behaviour; the grid is not showing up in the form until the project is saved and reloaded.. Thats why he had seven grids (after seven tries) when he reloaded the project.
That is correct, I was having the same problem.
So, by "Nothing happened" means "the grid didnt appear"?
i thought it meant, "Nothing wrong happened". Ill see if some
one that has FF can help me taking a look at this.
Elias :)
Egrid32 was making a wrong check for the string of parameters, since the line was empty creation was being aborted, seems like i accidentally tried to "Improve" the code by adding this error checking and forgot about Firefly, it creates the Grid Without parameters. Egrid32 Now is creating a grid with a size of 20 x 100 by default in case the string is empty. Since PowerGrade week came i couldnt get Firefly to test it.
I apologize, this change it was made by mistake, All registered Egrid32's users have already been sent a Correction and the demo was updated.
Here is the link for the Download of the corrected one V3.04.04:
www.sweetheartgames.com/EG32PRODEMO.zip
Haakon, i hope you like how Egrid32 Works in Firefly. :)
Elias :)
It now works correctly on my system.
Great Elias.. :D
It doesn't really matter if you made a mistake or whatever as long as you can manage to correct the error, we're all happy. The grid is now behaving as expected when inserted. But compilation still raises the "484 - Requires sub or function" error unless the line is rem'ed;
%EG_GETNEXTUNUSEDINDEX = %WM_USER + 247 ' If there are deleted cells, this function will return the next unused index, you can recycle cells that are deleted. just change flag %EG_UNUSEDINDEX to false.
Btw; Isn't 20x100 fairly small for standard-size on the grid?
20 x 100 is a tiny grid, but since it is only for designing i think it will do,
the grid size will be as desired when compiling. 20 x 100 is only to "check"
how the properties will look on the grid.
By the way, i dont know what can be wrong about this line:
%EG_GETNEXTUNUSEDINDEX = %WM_USER + 247 ' If there are deleted cells, this function will return the next unused index, you can recycle cells that are deleted. just change flag %EG_UNUSEDINDEX to false.
As you can see it is a Simple Equate definition with a comment, just like
many others there!! Here some questions:
1.- Is that the line found in the INC file i just uploaded? Or is it somewhere else in the project?
2.- The rest of the samples compiles OK?
But i tried compiling many times here (Non firefly samples) and it compiles OK, i cant test in Firefly, I dont want to assume, so, lets just ask Paul what can be wrong here... The only special thing about that line is
that it has the longest comment of all strings in the Include file, maybe a bad handling of the comment? Please, try deleting or shortening comment
to see if it makes any diference.
Paul, are you there? Lets spot the problem.
Elias :)
Elias, you're probably right - try shortening the comment. If that fixes it then I know what the problem is.... otherwise, we'll have to dive deeper into it.
True, as an equate definition it shouldn't be able to do much harm. I've looked into your suggestion about the lenght of the comment. Previously I just ignored thinking of the length as a brief 'count' showed it was 'only' 206 characters (not beyond the limit as I recall reading somewhere here). But it seems like that's to much. Reducing it by 12 characters, down to 194 only, will make it compile fine. I guess the easiest way to avoid this would be to shorten the description slightly in your next 'update' of the include file. :thumbsup:
Paul; 194 vs 255/256 characters total line length, and the error suggesting a error 484.. - Worth looking into, or..?
Quote
I guess the easiest way to avoid this would be to shorten the description slightly in your next 'update' of the include file.
You got it Haakon. However, im sure Paul will also want to do something about it, just in case more controls have long comments.
Elias :D
Yes, - I guess he does..
I too noticed the problem with compilation and the long source line. I just deleted the last part of the comment to shorten the line and it compiled without problems.