[REL] GUI Editor 3.1.3

[Rm-Dj]

this version is Great . thank you

[Dealman]

As for bug reports, I can't tell whether I'm doing something wrong or not.

But more often than not, whenever I click to change for example Start X or End X and etc, it'll 2 or 3 or sometimes all of these options with the proper one at the very back of them all. Thus having to close 2-3 windows before I can change what I want.

Nothing major, of course. I'm actually not sure what causes it.

[Remp]

As for bug reports, I can't tell whether I'm doing something wrong or not.

But more often than not, whenever I click to change for example Start X or End X and etc, it'll 2 or 3 or sometimes all of these options with the proper one at the very back of them all. Thus having to close 2-3 windows before I can change what I want.

Nothing major, of course. I'm actually not sure what causes it.

This is actually a really great catch, thanks for the report!

It seems to be to do with the menu item overlay button handling. If you hover over the overlay button on one item (e.g. Set Start X) then move the mouse downwards onto the next item (Set Start Y) without moving the mouse left or right it will fail to properly detect that you are no longer inside the first overlay button (Set Start X). Then when you click (on the Set Start Y overlay button), it thinks you are inside both items buttons and processes both handlers. If you start at the top and go down the whole menu it will even open them all!

This will be fixed in the next version.

[Dealman]

Sweet! Can't wait for the update

Another thing I would like see introduced would be the ability to "lock" certain elements. For example, I like to draw a big black screen as a background - sort of an old habit from working with Photoshop.

But doing so, I can't ever add anything because when I right click that, it assumes I want to edit it. What I'm asking for is something like this;

1. I draw a black rectangle, image or whatever which covers the entire screen.

2. Add some right-click option to "Freeze" that element.

And then for unlocking it, I guess some keybind or whatever. This isn't really something important, just a thing of convenience

[Remp]

GUI Editor 3.1.2 update:

- Changed "Shadow" and "Outline" options of DX Rectangles to use DX lines rather than drawing an offset rectangle

- Added "Set default size" menu option to DX images

- Made "Outline" and "Shadow" on relative DX items output the correct code (+ improved loading relative DX a little)

- Added "Locked" menu option that stops right click detecting the element (can be accessed/bypassed by holding ctrl)

- Added "Set outline colour" and "Set shadow colour" to DX items with shadow/outline options

- Fixed menu item overlay buttons not properly detecting mouse exit event

- Fixed problem with the "Automatically resize output window" setting when generating DX code

MTA Community link

As usual please let me know of any bugs/errors that you get, they are very helpful in improving the GUI Editor!

[Dealman]

Like Tina Turner would've said; "You're simply the best!"

[Castillo]

I can't seem to find how to "lock" elements.

[Remp]

I can't seem to find how to "lock" elements.

Hold ctrl (either left or right) while you right click an element and the menu will have an extra "Locked" item at the bottom. Once it is locked you can't right click on it again unless you are holding ctrl.

If that doesn't work, something must be wrong!

[Castillo]

Oh, perfect, I thought having to press "cntrl" key was just when you wanted to unlock it .

Good job man, keep up the good work!

[Dealman]

I can't even express how much better it is to work with now

Do you think it would be possible to make it so we can assign a DX Rectangle/Image as a "parent"? So all DX stuff we draw afterwards have their positions relative to that parent, instead of the screen resolution? This would speed up the process of making movable DX windows

[Remp]

Do you think it would be possible to make it so we can assign a DX Rectangle/Image as a "parent"? So all DX stuff we draw afterwards have their positions relative to that parent, instead of the screen resolution? This would speed up the process of making movable DX windows

I suppose it is technically possible, though the output code might be a little odd (especially if they are toggled relative). Keeping that parent relationship when loading dx code back in would also be very hard to do.

I think the main problem with things like this is that the way the output code is designed will depend on the specific situation you are using it for and the developers coding style. For example, does it just hard code (parent position + child offset) into every single position argument (which isn't very usable/manageable for a human, and certainly not very easy to modify), or does it start creating variables that store the parent positions and pointing to them in the child position arguments. If GUI Editor starts defining local variables in its output, how extensive should that support be? It is very likely that people could design their code to fit their specific use case (and modify the output to match) in a far better way than the GUI Editor would ever be able to.

[Castillo]

Adding that would be rather useless to be honest, this resource already makes our designing a lot easier.

[Karoffe]

Ehm, I guess this could be considered as a bug,

When I make a Dx rectangle relative in a resolution 1440, 900 and the size of the rect is 1440, 900 and test it in higher resolution it gets automatically re-sized to 1440, 900 that happens in the preview resolution option..

[Remp]

Looks like you are right, it appears that all elements won't resize properly when testing in a resolution higher than your own.

This seems to be an MTA limit, for some reason it won't allow you to create GUI elements larger than your own resolution. I tried a few variations of this in runcode, but it just disregards sizes bigger than my window:

Executing client-side command: button = guiCreateButton(0, 0, 1920, 1080, "", false) 
Command executed! 
Executing client-side command: guiGetSize(button, false) 
Command results: 1680 [number], 1050 [number] 

This also effects the DX items in the GUI Editor since they are technically implemented as masks drawn over GUI elements under the hood. I'm not sure there is anything i can do about this unfortunately, unless the MTA limit can be removed or worked around (if anyone else has any information about this, i would be grateful for it). Sorry!

[FlyingSpoon]

Loving the new interface and work,

A lot of bugs fixed also!

[TheSmart]

Great job man!

Hope in new version you will add dxCreateWindow,Dxbutton,etc....

[Anubhav]

Great job man!

Hope in new version you will add dxCreateWindow,Dxbutton,etc....

Hey, it's not a DX libary but just a editor to MTA GUI/DX functions.

[xXMADEXx]

Great job man!

Hope in new version you will add dxCreateWindow,Dxbutton,etc....

You should check this: https://github.com/Woovie/dxGUI

[TheSmart]

Great job man!

Hope in new version you will add dxCreateWindow,Dxbutton,etc....

You should check this: https://github.com/Woovie/dxGUI

Thanks but how to use it? i try to get it but i fail D:

[JR10]

https://github.com/Woovie/dxGUI/archive/develop.zip

[FlyingSpoon]

Any exports?

Any wiki pages to start people off, it seems really useful I would love to use it

[WhoAmI]

Any exports?

Any wiki pages to start people off, it seems really useful I would love to use it

https://wiki.multitheftauto.com/wiki/Resource:DxGUI

[Castillo]

That wiki page is not for these scripts, it's for this resource:

https://community.multitheftauto.com/index.php?p= ... ls&id=4871

[WhoAmI]

He is asking for dxGUI, or may I wrong?

[Castillo]

He was asking for exported functions list or a page with info about this:

https://github.com/Woovie/dxGUI/archive/develop.zip