DarkEDIF - Taking suggestions

[LB]

I don't go on CC when I'm angry because it makes me angrier

[Phi]

You're angry too often then...

[Dines]

For pity's sake everyone, please get back on topic . Some of us actually want to know about Dark EDIF, you know

Can we have more control over menus? Presently, I think the SDKs tend to micromanage the menu systems (in my opinion anyway), which is a pity because it's an opportunity to really create a powerful interface for our extensions. Things like icons on our menus, for example, and greying options out depending on our properties, stuff like that.

It's an aspect of extension development which I think gets overlooked at present.

[Phi]

For pity's sake everyone, please get back on topic . Some of us actually want to know about Dark EDIF, you know

I'm desperately trying to get an admin to clean up this thread. Jeff did his usual "I'm suddenly not here when Phi's talking to me" on ClickConverse and I'm not sure other admins can edit this particular forum.

Can we have more control over menus? Presently, I think the SDKs tend to micromanage the menu systems (in my opinion anyway), which is a pity because it's an opportunity to really create a powerful interface for our extensions. Things like icons on our menus, for example, and greying options out depending on our properties, stuff like that.

It's an aspect of extension development which I think gets overlooked at present.

It's an interesting idea. I'll look into implementing icons and such. In EDIF, you can disable items, but not at runtime. rSDK micromanages the menu support, and EDIF completely removes most of the support. I haven't modified that particular aspect beyond optimisation (changing a pointless loop to an array, removing three unused variables from a struct, creating container-aware generation). So I can look into menu icons and see how they would work.

I'm considering adding a "Depends" icon for the menus which would allow you to set a submenu to depend on a property being selected (i.e. only show "Advanced" submenu if "Advanced usage" is checked in properties). But I haven't finished with DarkEDIF properties either, I'm stalled on MMF2's incredibly basic form of edittime->runtime property copying.
My latest blog post covers menu items to some extent. My next post will be another a/c/e example and will go into more detail on what you can tweak and to what effect.

[Phi]

Alright vast herds of fans, DarkEDIF had another update about 23 minutes ago and now has fully working JSON properties! Including unlimited-length strings, as many languages and preferences thereof as you want, and no reason to throw cake out the window!

Well, the last part is optional. You can still code your own properties if you're into maintaining compatibility with older objects (i.e. Bluewing uses old properties to ensure switch-ability with Lacewing).

But if you want to bid farewell to the days of changing several variables and using preprocessor definitions for your properties, this update gives you the ability to set up a property just by editing is the JSON - the way it should be.
DarkEDIF's fancy code will take care of all the reshuffling of data when strings change length, all the precise memory editing when numbers change, all the weird combo box crud that no one on the planet likes looking at for more than a 15.3 seconds... you just worry about the JSON and if your translations were correct.

You can add your own variables to EDITDATA despite all that fancy code - DarkEDIF requires just two properties, preferably at the end of EDITDATA. It'll automatically move your data across with its own properties, keeping your settings intact.

Tested fully:
• Editbox Number
• Editbox Text (allows forcing of upper/lower-case)
• Static text (not stored anywhere but in the JSON, no extra memory space wasted)



Unfortunately MMF2 doesn't appear to provide all the property options that the properties should have available. Despite passing restriction flags, such as "this property should be bold", MMF2 ignores it and makes nothing bold.

Because reasons.
So don't assume it's me for those


Also, Bluewing has had a stability update.

Download link is here. Should be fully stable and comes with a dodgy edited version of LB's help file.

£20 by PayPal to the first person who can isolate a crash. Only the first person, mind. I don't want to be bankrupted by an ego problem >_>

[happygreenfrog]

Okay, time to work on finding and isolating a crash in Bluewing. :P

Just so you know, I don't have a PayPal account, but my parents do, so I might be able to ask them about it if I succeed in finding a crash.

EDIT: Wait, I just realized I don't have MMF2 on here yet. Oh well, I guess I can wait, I still have time.

[happygreenfrog]

Phi, I've found a crash in Bluewing. See the attached example. If you check the "automatically clear binary" checkbox, then it will no longer crash. Is that good enough for you? It actually was able to crash my whole computer. You need to leave the example running for long enough for it to crash, though (it will probably give you an error that it was sending a message that was too big before then, but you need to keep it running after that point). If it doesn't crash after 5 minutes, I would like to see a screenshot of that, since it probably means you have a lot of RAM.

[LB]

You're reporting user error as a crash? Exhausting a program's memory intentionally is your fault, not Phi's.

[happygreenfrog]

He specified a crash, he didn't say that it couldn't be something like that. He thought it was immune to all crashes (which would include the kind I put up), but he was wrong (as I've proven). That's what he has implied, anyway (I think it was on ClickConverse). We'll just have to see if he counts it, though.

[Phi]

It actually was able to crash my whole computer. You need to leave the example running for long enough for it to crash, though (it will probably give you an error that it was sending a message that was too big before then, but you need to keep it running after that point). If it doesn't crash after 5 minutes, I would like to see a screenshot of that, since it probably means you have a lot of RAM.

This is a user error Mr. HGF. The binary/stack messages are allocated memory for as they need it.
If you don't check to automatically clear the binary, the binary will get larger and larger until the program runs out of memory and cannot create more.
At which point this kicks in to report the problem.

A crash is expected behaviour in these conditions - the fact Bluewing didn't crash, but your computer, suggests a different extension/program tried to get more memory and failed to handle the lack of it properly.

it will probably give you an error that it was sending a message that was too big before then, but you need to keep it running after that point

That's a fairly good indicator that you're screwing up somewhere. I think the limit for messages is 2 or 4gb.



If you're for example adding a byte with value 503 and Bluewing crashes, that's a bug I need to dish out for. If you join a channel, send a message on subchannel 256 and all the other clients flee to the Netherlands, that's another one.
Using up all the available memory on the system isn't a crash that would be a fault of the extension. In fact Bluewing should be complimented for handling it in its stride, despite other programs around it not doing so.

So no payout on that one unfortunately Mr. HGF. You haven't gotten the extension to crash, just to do something that in real world scenarios will not happen.