Ofp dialog editor

[uiox 0]

Good work

If you want idea of something very easy to use take a look to the yahoo! pagebuider only the text management, it's java applet for creates HTML.

Snap to grid yes, but before little move by arrow keys.

Other idea a pict with different commands bar of OFP, resizes with your window...

And don't forget you can write all parameters for a control, if example backgroundcolor is not use by it : no problem

About names of controls the order in the array defines the order where you go with arrow key in active control, the last in is first show.

Ex: {but1,but3,but5,butfirst}, when dialog is show butfirst is active, if you do down key but1, but3, but5... And up key but5,but3.

For ID an offset (1000 +1, 1000 +2)

For style, type, use directly the number in editor (but string in combo box in display ), so you don't need #define

ex : title (with it you can drag the dialog on the screen) is 32, if you want center text it's 2, so a title center 32+2 =34, for fonts the string.

I have other ideas an tips about dialog but my english is not good enought for explain it here.

[Tychon 0]

I do intend to make the screen resizable, but I want to get the math just right, as currently everything would be screwed up if I let the window be resized.

The snap-to-grid will probably be implemented, when, not a clue. Whether I use mouse or keyboard, we'll see.

I know I could program it to add in specific control parameters, but the problem with that is it would require people always use the same resource class names. That is, text will always be defined as class RscText. Otherwise, the engine wouldn't be able to decide what parameters to add. If people would be willing to always use those defines, I'd be willing to implement it to add in all control parameters.

The ID does already increment, although it does start at 0.

As for selecting the controls with the arrow keys, I don't really see much use for that. Almost all operation with the visual control will be done by mouse, so it would be a little tedious to switch to keyboard and such.

As for the styles, I prefer to use defines as that makes the code much clearer. Yes, it does require people use ST_CENTER, but they can change that if they really want to.

And yes, hopefully this will eventually be as easy to use as Yahoo! Pagebuilder, hehe.

[Spinor 0]

Version used: 0.10a:

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">The ID does already increment, although it does start at 0.<span id='postcolor'>

One bug report about this: I created two controls (ids = 0,1), then deleted the first, and finally created one, ending with two controls that both had ids = 1.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">As for the styles, I prefer to use defines as that makes the code much clearer. Yes, it does require people use ST_CENTER, but they can change that if they really want to.<span id='postcolor'>

I also prefer defines but most of the time I already define controls on base classes where most of the properties like the style are already given. I would suggest (but this is really only a suggestion   ) to first concentrate on the geometry (so to say), and maybe later add further properties.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">As for selecting the controls with the arrow keys, I don't really see much use for that. Almost all operation with the visual control will be done by mouse, so it would be a little tedious to switch to keyboard and such.<span id='postcolor'>

I think, uiox just noted that one can cycle through the controls with the arrow keys WITHIN OFP, thus the ordering of the controls is important.

There is one small problem with placing a control: If the endpoint is not to the lower right of the start point, the control is not drawn and the click recognition gets out of tune.

BTW, the comma<->period is indeed due to the language settings. I resolved this in the Windows settings.

Spinor

[Tychon 0]

Actually it not drawing the control if the second click is not lower-right than the first click is intentional. The current method of figuring size and such depends on it working that way. It would spew out negative numbers and such at the moment if I were to allow you to place the second click above the first click. I may work on fixing that if it really is a bother.

As to the IDs, I haven't made any ID storage method, so you're right, it would create multiple IDs, as it just increments a variable. I'll convert that to a constant so it never goes down.

And as for setting the cycling order, I can't do much about that, you'll have to manually arrange the order of the code yourself. I could adjust the order inside OFPDE, but I can't do anything about it in OFP, sorry.

And yes, I really want to fix up the math and sizing methods before I work on anything directly control specific or such. Core features first. I don't suppose it's that difficult to have the user type a couple lines, heh.

Anyways, I'll work on manual resizing and I'll fix the ID counter. v0.10b should be out in an hour or so, depending on if I'm not interrupted by my family again, heh.

Addendum:

Well uh, that was simple. I fixed the ID counter, and you can manually resize controls. Now the exact sizing might be a little off, but only by a pixel or two. Anyways, v0.10b is up and available for download. And to update a control's size, simply go to the editor, adjust the W and H parameters, then click on Update Display under the Dialog menu.

[Tychon 0]

Ack, I found a nasty little bug in the manual resizing code. At the moment, your control may disappear if you use a perfectly even W or H value. Such as 0.1 or 0.25 for example. Simply add on a few extra small numbers, such as 0.2500126, and it should work. Don't worry, I'm working on fixing this, but it may take a little bit.

[Spinor 0]

Hey man, you are faster producing than I can test

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">Actually it not drawing the control if the second click is not lower-right than the first click is intentional. The current method of figuring size and such depends on it working that way. It would spew out negative numbers and such at the moment if I were to allow you to place the second click above the first click. I may work on fixing that if it really is a bother.<span id='postcolor'>

Its not so bad once you get used to it. At first it is just a little confusing. What about the following algorithm for extracting x,y,h,w from (x1,y1) and (x2,y2) (irrespective of their relative position):

w= Abs(x2-x1)

h=Abs(y2-y1)

x=Min(x1,x2)

y=Min(y1,y2)

One suggestion: Could you make the type of a control optional but instead the name mandatory (every control needs a name but it is not necessarily based on a class)?

Spinor

[Tychon 0]

Edit:

D'oh, I thought that was in reference to manual resizing. Actually, that may work as far as placement goes, I will try it out later on.

But as for manual resizing, I discovered an interesting little thing. While 0.25 may not work, 0.250 does. Go figure. So for now, just add an extra 0 if you need a number like that. I dunno why the hell it does that.

[Tychon 0]

v0.10c is now available here. Right click on the link and click 'Save Target As..' to download.

 -> Several math tweaks, hopefully it will be slightly more accurate.

 -> Updated the control hint. Hints will now display name, as well as X and Y positions.

 -> Updated the painting, thanks to Spinor's suggestions which gave me some ideas. You can now paint starting with either the bottom-right or the top-left corners. Also, you can right click to cancel a current paint process - that is, if you've clicked once, simply right click to undo your first click.

 -> Also Spinor's suggestion, controls no longer require a type to be defined after. Being as names are automatically created, no parameters are required at all.

[GAMEER_77 0]

Nice work.

I think it'd be good if, when you hover your mouse over a control, then the control name, action and so on come up in the hintbox.

And, when more types are made, put the name of the control somewhere in the box (So if it was a slider it'd say CT_Slider or something )

.....Thoughts......

Gameer

[Tychon 0]

Well, I'm not really going to add in the actual types, as that would force the user to use the define CT_SLIDER, for example.

But as for hints, how about in the insert box I add a little panel that lets you decide what will be added into the hint for that control you're creating? It'll require a little rewrite, I'll need to add some extra data properties to the objects that represent the controls, but it can be done. Plus if I add in these properties it would pave the way for greater.. control, over controls, for later on.

[Spinor 0]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">But as for hints, how about in the insert box I add a little panel that lets you decide what will be added into the hint for that control you're creating?<span id='postcolor'>

You could also simply display the type (if given) in the hint. In most cases controls are based on sensible base classes like RscButton. This should be enough info.

Is it possible to make the boxes transparent (so they don´t hide each other), or would this mess up the select´n´drag feature? It is often the case that controls are "stacked" on each other, like buttons over a background.

[Tychon 0]

I am working on opacity and such, but this will be implemented along with coloring - so that won't be available just yet. But I am looking at layer settings of controls and such, so the user can custom stack controls and such.

And what I meant by custom hints was a selection of check boxes for things such as X, Y, W, H, resource type, things of that nature. So a person could just have the name in the hint of one control, the name, width, and resource in another, and so on and so forth. Just a thought.

[Tychon 0]

After fiddling with some annoying code for the past couple hours, I've come to discover that opacity control won't be easily done without some major writing to the control. So, it is unlikely that transparency will be implemented any time soon. It probably will make it in at some point, but that will take a bit of work, so until the important stuff is finished, that will have to wait. Unless it's in high demand or such, of course.

As for the layering, that's coming along alright - I may have a release out with that sometime in a couple hours. Maybe.

[Tychon 0]

Yay, v0.11 of DE is finished! I got tired of all the letters, figured it'd had enough updates to merit a number, heh. Same download link as usual, so I won't paste it here. At any rate, here's what's been updated.

 -> Several more tiny math tweaks. I fiddle with this a lot, can you tell?

 -> Customizable control hints. Hints can now have specific parameters, or a control can have no hint at all, it's up to you.

 -> Edit menu. Right click in edit mode now brings up a popup menu, allowing for more potential use in edit mode.

 -> Layer control. This only affects display in the EDITOR though, this will not affect your OFP dialogs.

Being as this update has quite a few new features, please be on the lookout for any glitchs, the possibility of them is higher in this release than most of the past releases.

[Spinor 0]

Hi, found no new bug yet, although I went havoc creating, editing, deleting controls .

The layer feature works great and is very useful.

The Hint control also works fine, although I have to say, inserting a control is now a little slow. Is it possible to combine the two menus (control properties, hint properties) into one? Maybe of the following form:

Name: _ _ _ _ | x|

Style: _ _ _ _ | x|

x: _ _ _ _ | |

etc.

The lines represent the editing fields (x,y,h,w are prefilled with the box values). The | | represent a checkbox that determines whether the parameter is to be "hinted" or not.

[Bullz_eye_on_my_back 0]

Oh my gosh Tychon is a machine!! He is just taking requests and pumping them out! Keep up the good work!

[Tychon 0]

Well given the relative rate of time I spend on my computer versus the time I spend being around humans, yes, I am a machine.

[Bullz_eye_on_my_back 0]

haha... well I guess you can call me a book then!! (wishes these professors wouldn't give this much homework) Well you can for atleast a couple more months lol

Look! He even replies fast too!! Whew!!! MAAACHIIINNE!!!!

[Tychon 0]

No guarantees, but sometime tonite or tomorrow, you may see the first basic rendition of loading already created dialogs. It'll probably be ugly at first, but here's to hoping that I can get it done soon.

[Tychon 0]

Alright, I'm doing some major tweaking on the code, so there won't be an update tomorrow. Maybe sometime this weekend, but we'll see how that goes.

I'm hoping these fixes will help in many areas. You as the user might not see a whole lot of difference, but it will make the code far more clean and modular, which means updating or adding things will be easier and faster.

However, this doesn't mean there won't be any new features in the next update. I do have some things planned, but it's too early to really say what will make it in and what won't, so I'm not going to list them. Oh well, you'll see them when I release v0.12 at any rate. The version should give an idea of the amount of updates and features I'm hoping to add in. But again, we'll see.

[The_Captain 0]

One thing I would like, is the option for the text on a control or object to display on the control itself, in the same way that it would in OFP. Not really nescessary though... For now I just want to be able to load in my own ext's...

Also, perhaps you could have an option of where to put the dialogs and controls within the ext. For example, this is how I make my ext's manually...

main dialog {

controls[] = {control1, control2, control3, etc}

all controls and objects defined

};

child dialog : main dialog {

controls[] = {control1, control2};

}

child dialog 2 : main dialog {

controls[] = {control3, control4};

}

I dunno, that's just the way I do it. Makes the ext a LOT easier to edit, because it's easier to keep track of which dialog has which controls. The desc.ext's get b i g the more you write...

Also, does anyone know the code to do the whole include.h thing, so we can pehaps write some of our dialogs in separate files and 'include' them in a main ext? Perhaps tychon could implement this somehow... saving dialogs as other files and including them... I know snYpir did it in the support pack, so I guess I'll just go unpbo the scripts and poke around.

</ramble>

[Tychon 0]

You just want to give me work now don't you, heh. At any rate, yes, I am alive and yes I am still working on DE. No, I don't have any updates ready, sorry.

Real life caught up with me a bit and I got a little burnt out, so I'm a bit behind. However, I do have some stuff written up, and I am of course looking for ways to improve the project. At any rate, here's a little write up of what is guaranteed to be in the next release. No I don't have a release date, there's still a bit of work that needs doing, and there are some other things that I want to see if I can squeeze them in the next release.

First new feature, limited or complete removal of indexes. It's still a bit too early to say if this can be completely removed, but the new system will limit the amount of indexes required. So far I can assure no more "boxing" will be required, that is..

// Control0

// ~Control0

If anything, it will be one line at the end of a control, like so.

// ~ControlName

While this isn't perfect, it is much nicer, in my opinion. But who knows, I may think of a solution to nicely remove indexes all together. We'll see.

Second feature, multi dialog support. No more working on one dialog per EXT. The next release will support as many dialogs as are in the EXT, and of course however many controls are in the dialogs.

Third feature, colors! I know this really isn't terribly important, but I have had some requests for it, so this is going to make it in the next release. Just basic stuff, no alpha blending unfortunately.

Fourth feature, internal resources. That is, the DE will understand that RscButton will have a SoundEnter, SoundPush, SoundClick, and that RscText will have a font, sizeEx, and colorText properties. Whether or not these resources will be editable still remains to be seen, but I intend to make them custom definable. I.E., you give it the name, and DE understands it throughout the EXT.

Fifth "feature". A reworked layout. I'm tired of that immobile box look with the little tab. So I have a new MDI window based layout for DE. In simpler terms, you get a couple windows that you can move around inside the main window.

All the previous features are guaranteed to make it into the DE in one form or another. Of course several of these will be completely new to the DE, so as always, new bugs may be introduced so please be patient with me.

Also, I'm going to attempt to give the dialogs a more "true to life" feel to them. That is, text controls will actually be text, image controls will actually display an image, and buttons will have the button text on the face. No guarantees on this, but I'll try to get it in anyways. Happy?

[The_Captain 0]

Yee.

[nierop 0]

Hi Tychon, just wanna show interest in your project. How is it comming along? Keep up good work!

Thnx,

Pimmelorus

ZEUS OFP community

[nero12 0]

Give me good LINk Pleasee