Gump Studio

[Bradley]

Please post the bugs / annoyances in Gump Studio you would like to see fixed. That's right, I finally have enough free time, and managed to find the box I packed the CD with the source code away in.

My first goal is to fix any problems with the current version you guys might have.

Thank RoadMaster for finally getting me motivated enough to find the source code again. He's also the one working on the new Export to RunUO Script Plugin.

[Bradley]

I forgot to add, the download for Gump Studio is back at www.gumpstudio.com

[Setharnas]

Sounds great, thanks!

My biggest annoyance is the upside-down scrolling in the gump browser when scrolling down (scrolling up works as it should). That tool alone is, imho, one of the most useful gump related tools for UO ever, but when I click the scrollbar to scroll the list down a page I don't want it to give me a headache by scrolling in the new pictures from the top, just as if I had clicked to scroll up.

Oh, and I'd like to access the browser from a button on the standard UI, for quick browsing when you just need to find a specific gump for code outside GS. This is nothing important, adding a background and modifying its ID works just as well - it just doesn't feel right.

Otherwise, GS is great, thanks for that.

[Bradley]

Originally Posted by Setharnas

Sounds great, thanks!

My biggest annoyance is the upside-down scrolling in the gump browser when scrolling down (scrolling up works as it should). That tool alone is, imho, one of the most useful gump related tools for UO ever, but when I click the scrollbar to scroll the list down a page I don't want it to give me a headache by scrolling in the new pictures from the top, just as if I had clicked to scroll up.

Oh, and I'd like to access the browser from a button on the standard UI, for quick browsing when you just need to find a specific gump for code outside GS. This is nothing important, adding a background and modifying its ID works just as well - it just doesn't feel right.

Otherwise, GS is great, thanks for that.

I may be able to break that browser out into a stand-alone program if you'd like.

Which browser is scrolling backwards, the Image Browser, or the Item browser? I don't think I've ever seen this happen. If it's the Image browser then I'm not sure I can fix it because I don't control the scrolling on that one. It's just a plain windows forms based listbox with OwnerDraw set to true.

As a quick summary of whats been fixed so far...
You can now manually browse for the UO data file directory.
Serialization for TextBoxes, CheckBoxes and RadioButtons now fully serializes everything.
TextBoxes now have a MaxLength property.

Most of my time has been spent trying to get it to compile and work properly in Visual Studio 2008 using the 2.0 framework.
I'm not sure what Roadmaster has fixed in the export so far.

[Setharnas]

Originally Posted by Bradley

I may be able to break that browser out into a stand-alone program if you'd like.

I don't think that would be necessary, as GS doesn't take hours to start. It's fine as it is.

Which browser is scrolling backwards, the Image Browser, or the Item browser? I don't think I've ever seen this happen. If it's the Image browser then I'm not sure I can fix it because I don't control the scrolling on that one. It's just a plain windows forms based listbox with OwnerDraw set to true.

Too bad, I was talking about the image (GumpID) browser.

To recreate what I'm talking about: just open GS, click on the 'Background' button, in the info pane focus the GumpID, click the '...' button next to it and just click inside the vertical scroll bar to scroll down. The new images scroll in from the top, but they should come in from the bottom. Scrolling up works as it should.

I'm not sure what Roadmaster has fixed in the export so far.

TBH, I wasn't even aware he was working on it...

[Bradley]

Originally Posted by Setharnas

I don't think that would be necessary, as GS doesn't take hours to start. It's fine as it is.



Too bad, I was talking about the image (GumpID) browser.

To recreate what I'm talking about: just open GS, click on the 'Background' button, in the info pane focus the GumpID, click the '...' button next to it and just click inside the vertical scroll bar to scroll down. The new images scroll in from the top, but they should come in from the bottom. Scrolling up works as it should.



TBH, I wasn't even aware he was working on it...

The scrolling bug doesn't seem to be happening to me. I do kind of remember it a bit from a long time ago now that I think about it. Unfortunatly I think it's a bug in one of the control libraries from Microsoft. I can look into manually handling the scrolling like the way the static item browser does.

I don't actually get into the RunUO scripting, so I don't know how gumps are handled in script (other that taking a quick glance at some code). That's why Roadmaster is working on the export plugin. He's much better than I am at knowing what would actually go into a gump script.

[Bradley]

Adding Cliloc Browser Property Editor so you can browse and search for the ID through a visual browser like ItemIDs and GumpArtIDs.

I'm also adding tooltip and TiledImageButton support.

Were any new Elements added to the client since the last version of GS that i've missed?

*edit* ohh yeah, cropped labels are in too.

[Jeff]

Bradley, the biggest gripe about Gump Studio is that once u get 50 items on the screen, moving any of them 1 pixel at a time is terribly slow. I believe this is due to the way you handle Undo and Redo stacking. As a test you could disable that code and see. There are better ways to do it. I know its possible to get rid of this because I did in RunUO:GDK. Another great idea would be making the selection of items done by pixel calls. If you click on an item, the order of checking to see if the item has been selected should be

if(gump.bounds.contains(point) && gump.image.getpixel(point - gump.location) != color.black))
{

}

This makes selecting items that overlap others ALOT easier.

[~Vlad~]

Its kinda tricky trying to line buttons or images up in the middle of a background etc without doing some calcs of the size of the gump etc... Maybe if you could display the coordinates of your cursor on the window this may help to allign things a bit? Or even a kind of "ruler" you could use?

Regards, Vlad

[Bradley]

Originally Posted by ~Vlad~

Its kinda tricky trying to line buttons or images up in the middle of a background etc without doing some calcs of the size of the gump etc... Maybe if you could display the coordinates of your cursor on the window this may help to allign things a bit? Or even a kind of "ruler" you could use?

Regards, Vlad

You should be bale to do this easily by selecting the items you want to center, including the element you want to center them on. Once they are all selected be sure that the background element is the current item (has the white selection box). Right click this item, choose Positioning > Center Horizontally.

I think displaying cursor coords, and element locations coords is a great idea.

[Bradley]

Originally Posted by Jeff

Bradley, the biggest gripe about Gump Studio is that once u get 50 items on the screen, moving any of them 1 pixel at a time is terribly slow. I believe this is due to the way you handle Undo and Redo stacking. As a test you could disable that code and see. There are better ways to do it. I know its possible to get rid of this because I did in RunUO:GDK. Another great idea would be making the selection of items done by pixel calls. If you click on an item, the order of checking to see if the item has been selected should be

if(gump.bounds.contains(point) && gump.image.getpixel(point - gump.location) != color.black))
{

}

This makes selecting items that overlap others ALOT easier.

I'll see what I can do about optimizing the display of a large number of elements. I'm fairly sure it's not related to the undo code, because an undo point is only created after the move has completed (ie, on mouse up of a drag), not durring the move. It's hard for me to test performance because I do not have an older / slower computer to test it on.

As for "pixel perfect" element selection, I think an option for this would be a good idea. I personally prefer the stack order selection on bounds, it makes it easier to select small items, but agree that some people like having it work on pixels.

[Bradley]

Originally Posted by Jeff

Bradley, the biggest gripe about Gump Studio is that once u get 50 items on the screen, moving any of them 1 pixel at a time is terribly slow.

Ahhh! I think I finally understand. You mean when you select an item, and hold down the arrow key to move it along? If that's that you mean then yes, that would cause a ton of undo points, and screen refreshes to be generated.
I hadn't thought about being doing large moves with the arrow keys. I beleive I can fix this.

[Jeff]

Originally Posted by Bradley

I'll see what I can do about optimizing the display of a large number of elements. I'm fairly sure it's not related to the undo code, because an undo point is only created after the move has completed (ie, on mouse up of a drag), not durring the move. It's hard for me to test performance because I do not have an older / slower computer to test it on.

As for "pixel perfect" element selection, I think an option for this would be a good idea. I personally prefer the stack order selection on bounds, it makes it easier to select small items, but agree that some people like having it work on pixels.

cool, feel free to look at my code on RunUOForge for the RunUO:GDK project, Ive since given it to Outkast due to time restrictions and lack of motivation. But its working and its fast. Granted I have a mean machine, but i could get around 1500 objects on the page and move them without issue. I counldnt do this with gump studio. If you need any info let me know, and if u want to use any code from GDK feel free.

[Bradley]

Originally Posted by Jeff

cool, feel free to look at my code on RunUOForge for the RunUO:GDK project, Ive since given it to Outkast due to time restrictions and lack of motivation. But its working and its fast. Granted I have a mean machine, but i could get around 1500 objects on the page and move them without issue. I counldnt do this with gump studio. If you need any info let me know, and if u want to use any code from GDK feel free.

Do you have the snapToGrid plugin loaded when the slowness happens? I think I found a problem in snapToGrid that would cause some really slow drawing.

[Jeff]

Originally Posted by Bradley

Do you have the snapToGrid plugin loaded when the slowness happens? I think I found a problem in snapToGrid that would cause some really slow drawing.

hoenstly i havent used GS in a long time. so i dunno.

[Bradley]

Originally Posted by Jeff

hoenstly i havent used GS in a long time. so i dunno.

I'm still having problems finding the slowdown you are talking about, but I've made a few changes to try and help.
1. Snap to Grid plugin's grid drawing code has been optimized, making it run about 10x faster.
2. The undo point for moving items with the arrow now happens when you release the key, instead of on every pixel move.
3. I've added "Arrow Key Acceleration", The longer the arrow key is held down the faster the Element will slide across the screen.

[Jeff]

Originally Posted by Bradley

I'm still having problems finding the slowdown you are talking about, but I've made a few changes to try and help.
1. Snap to Grid plugin's grid drawing code has been optimized, making it run about 10x faster.
2. The undo point for moving items with the arrow now happens when you release the key, instead of on every pixel move.
3. I've added "Arrow Key Acceleration", The longer the arrow key is held down the faster the Element will slide across the screen.

i dont remember but does Shift+arrow move 10 pixels ?

[Bradley]

Originally Posted by Jeff

i dont remember but does Shift+arrow move 10 pixels ?

If you have the snap to grid plugin loaded, holding shift and pressing an arrow will move the element by the grid spacing.