Radiant Virtuoso Q1 Gamepack ver 2.many

[MadGypsy]

fuck that guy. Any presidential candidate that uses the words "fundamentally change" in reference to the free-est nation on the planet needs to be immediately shot and buried in China.

[MadGypsy]

6:39 - let's see where I am in 4 hours. I want to get back to where I was before the rewrite. IDK if I'll make it today but I'm about to give it a lot of effort.

I need to write an ambiguous graphics class. Which is kind of a lot. drawRect, drawRoundRect, drawElipse, drawCircle, fill, gradientFill, bitmapFill, moveTo, lineTo, curveTo... that's the gist but there is more like that. Then I need to write the interface that I spoke of earlier. All that will be followed by some gigantic loop process that reads my entire object and creates the actual elements that the child objects describe.

Hmmmm, I think that will get me back to a completed shell. BUT it will also have me starting the build menu with an entire display system in place. The way I create ui elements for the shell will be the same system I use for the app. That's the entire reason I rewrote it... so I can reuse a lot of the code. Not just for this app, though. Entire display system equals exactly that. I can use this system as my standard and create complicated elements with nothing but an Object descriptor and a class to attach it to.

That class does not even need to be compiled into the app or the shell. It could be compiled as an external library and my object will still find it.

[MadGypsy]

I'm working on the display engine portion of things now. This project is nutty cause so far I've actually only worked on 2 projects that aren't this project. I built flashShell which was necessary to this project and now I'm working on a display engine that is actually a continuation of my parsing delimiters project.

It's the best way to go though. As it stands right now everything I've mafe can be easily repurposed for other projects... actually that's not accurate. Everything I've made so far can SERVE its purpose in other projects. If I would have continued with my initial way everything would have been tied together as one thing and all future projects start from ground zero rebuilding the same shit I already built.

I believe when I finally start the build menu it will be cake. Stuff like buttons, checkboxes, form fields, etc will already be present in the display engine and it will just be a matter of writing a COS (cascading object sheet ™) in order to display it.

In short, I'm building a browseresque shell that runs on object notation as opposed to HTML so the app that is displayed within will be little more than a webpage written in a custom language. The real difference is my Object notation is the HTML and CSS of things and AS3 is my Javascript. Also, since the Object parser is entirely my creation I can make it do whatever I want. This means that eventually the Object could even possess some behavioral qualities. However that's down the road. If I added anything to my parser right now It would be the recognition of vectors and dictionaries.

Currently it only supports Objects, Arrays, Booleans, Number, Int(0xHEX style), Strings & null

[RL Clown]

AS3 is my Javascript.

What's a Javascript? Remember: I don't program things on a regular basis...

[MadGypsy]

Javascript is a browser scripting language. Most generally it's used to add or supress behavior and send or retrieve data.

[Spike]

> and send or retrieve data
like your date of birth, credit card number, username, and passwords.
javascript is a real joy.

here's an example of the horrors of javascript: wee avert your eyes! :s
(also, firefox broke their audio api, grr)

(hurrah for hashing passwords to avoid the server from ever seeing the actual password. https sucks)

[MadGypsy]

anybody using javascript to handle a form of personal data is an idiot (although JS can be used well to prevalidate form fields so the most simple field errors can be caught while you are typing) When I said send/retrieve data I was referring to ajax requests for things like vote buttons and other non-important things. Mostly just to query the database for simple data in a way that doesn't force a page reload like a form would.

I dislike sites that treat every user submission like a form. If I ex like something the page shouldn't completely reload. A background request should be made and the like button should be replaced with a message "you have already liked this" or "added to likes"... as an example

[MadGypsy]

Bah Humbug, grrrrrr, fuck!

I'm so so so friggin close to getting this display shit to work but, every time I fix an error I get a new one and now I've reached a point where fixing error A gives me error B and fixing error B gives me error A. That's like my worst friggin nightmare right there.

I have definite progress though. When I first tested all this code I have written, I had 4000 errors. It wasn't really 4000 errors though. I fixed like 5 things and the 4000 errors were replaced with like 3 new ones. I got rid of that three and now I have one but, like I said, fixing it makes one more and fixing that brings me back to the first one but from an opposite direction.

I really believe in my new system, I just need to step back from this shit, maybe print the entire codebase and tape it to a wall or something.

My old display engine method was based on the premise of loading every object and combining them into a super object, then traversing the entire object to create all the elements it describes. My new method is much cleaner.

Every visible thing extends a creator class. This includes the stage. The main object is dumped into the creator class for the stage. The creator only creates the top level object and all internal objects are delegated to the respective visual object which, runs the properties through it's own instance of the creator class. In this, I don't have one master creator trying to create everything. Each thing creates itself. Since the creator class does not contain any specifics, it's sub class can create specific rules for each of it's properties and these rules will not conflict or carry over to any other object.

I've (in a way) been working on this display engine for years. I've had various versions working throughout that time but I have progressed as a programmer and my methods of yore are not acceptable to me anymore. I know I'm right on the edge of getting this to work. There is some line or condition in the code (or needs to be in the code) that will pop and bring all of this to life in a working manner. I'd be willing to bet that error A and error B aren't even the problem, they are symptoms of something else. The real problem here is I have written an absolutely insane amount of code and now I'm having trouble keeping track of the scope. I'm gonna go out on a limb and a guess and say there is about 20,000 lines of code. I haven't actually counted but I know I'm in the pocket.

Ya know what, it's time to start a blank project that focuses on just this one thing I'm having problems with. Get that to work and I can edit the changes into my master code. I mean as stripped as possible. Get rid of all the parsers, file loaders, etc.. Write some static object directly into my AS3 and get some display stuff working from that.

yup, that's the next step. Hell or high water Imma get this to work. I have to. Creating my build menu with some static, non-reusable system isn't acceptable.Plus, I have other projects that will rely on this system. Actually, my next project after I finish this build menu is to write a GUI that will allow Objects to be drag/drop instantiated from a library and then save all of the instantiated objects to a byte file. Essentially it's what I am already doing but instead of hand-typing the object I can drag/drop it and adjust it's properties via a properties editor. Those properties are the object that will actually get saved and then fed right back into the system on app load, to do exactly what I'm stuck on accomplishing right now.

In other words, I will deprecate/obsolete my object parser by saving objects as objects instead of parsable text, and create a WYSIWYG editor as opposed to typing anything.

[MadGypsy]

got it! I didn't do any of what I said above, I just sat down and figured it out. There were some interesting errors but the most important 2 were a missing comma in my Object and accidentally setting autoSize to true instead of "left". Once I fixed those Object typos the stuff was still broken but it was no longer broken in a circle.

I came across one really shitty problem. You can't successfully apply a text format to a textField which hasn't been added to the display list (ie...is visible). My workaround is seriously ugly. Since the format is not globally accessible and there is ni way to predetermine all the classes that may utilize the textField, I set the format unsuccessfully while it's being created and then after it is added to the stage I reassign it like this

textField.setTextFormat(textField.getTextFormat())

apparently the unsuccessful part is only in a visual sense because the above line works. The only way that is possible is if the bogus format attept actuallt did attach its properties to the field. It's not very elegant but the alternative is to make it where unrelated classes have access to the format. It would also require reconsidering my interface cause there is no available function to return the format. Actually the entire point is to return instances of 100% completed elements in a factory pattern, making details visible to random classes defeats the entire point. So, var.format = var.format it is.

[MadGypsy]

this is perfect. I've got the shell almost complete using the display engine. All I need to make is a close button. Then I need to put back in the code for external stuff like, executing a cmd shell with arguments and retrieving the arguments that the hta recieved. That code is done, been done. I just took it out so it wouldn't be cluttering up my code while I worked on a different end.

in shorter, an hour from now I will be back to the build menu with a faux shell and display engine to build upon. That's WAY better than where I was 2 weeks ago and I'm glad I started over.I solved an awful lot of stuff in just a few weeks. Now if i could just solve stdOut, I may even fall right asleep with no puzzles keeping me up.

[PrimalLove]

I'm getting excited and I'm not even working on it!

[MadGypsy]

@PL - excited

me too. I needed a win. The complexity of this was starting to feel like - trudge, struggle, sigh. My display engine still has a long way to go but, not to finish this. I may need to make about 5 more display classes (button, checkbox, dropdown menu, etc) and it will be sufficient for my app.

[Dutch]

Good job man, love to read about progress.

[MadGypsy]

check it out. Here is my current display Object.

config:
{
	display[0]:
	{
		classPath:"app.components.CaptionBar",
		child[0]:
		{
			classPath:"app.components.core.GraphicsObject",
			properties:
			{	width:400,
				height:30,
				fillType:"solid",
				shapeType:"rect",
				lineThickness:0,
				lineAlpha:0,
				color:0x777777
			}
		},
		child[1]:
		{
			classPath:"app.components.core.TextObject",
			properties:
			{
				autoSize:"left",
				background:false,
				border:false,
				selectable:false,
				multiline:false,
				type:"dynamic",
				text:"Build Menu",
				y:3,
				x:3
			},
			format:
			{
				size:14,
				color:0xEEEEEE
			}
		},
		child[2]:
		{
			classPath:"app.components.core.GraphicsObject",
			cond:true,
			properties:
			{	width:400,
				height:30,
				fillType:"solid",
				shapeType:"rect",
				lineThickness:1,
				lineAlpha:1,
				color:0x000000,
				alpha:.01
			},
			mouseEvents:"MOUSE_DOWN"
		}
	}
}

This is still fairly rudimentary, but effective. The display[num] values are the ultimate display list for the stage and the child[num] values are child display elements of each display one.


I have full control of the appearance, dimensions and position of each element. I can also kick off initial events that need to be applied. mouseEvent can be a string oi an array of values. In this example, a bar graphic is created. It's only purpose is to be the caption bar dimensions and color. Then a text field is laid over the graphic to be the title. Finally, a virtually invisible sprite is overlaid over the entire thing. It has the same dimensions as the bar graphic. It also has a mouseDown event attached to it. The purpose of this sprite is 3 fold.

1) The bar graphic is of the type Shape and shapes cannot have events attached to them, not that it matters cause
2) The textField blocks mouseEvents for anything under it
3) Whereas the text field is not selectable, it was still changing the cursor to indicate it was over a textfield.

By covering everything with an invisible Sprite, I have mouse functionality over the face of the entire bar and also now have the ability to actually add that functionality, while also breaking the cursors recognition of the text field.

What is the mouseDown event for? You may ask. This particular bar is the shell caption bar. When you mouseDown on it and move around, the entire shell will follow on your screen. You may also now ask...how does it move when you never gave it a mouseMove event? Well, it's impossible to move unless you mouseDown first, so the code is designed to add the mouseMove, mouseUp and mouseOut events as you mouseDown. It also removes those events on any process ending mouse action (Up/Out).

My close button is not included in this object yet. I didn't post a pic cause it's a nothing. A grey bar with white text in the left corner, above white space that represents the rest of the app/shell. I can write better objects that would utilize gradients, layers, rotation, images, etc... and except for images (yet) all of it would work.

This is the "does it work?" version, and it does. Even shell screen positioning on mouseMove. Funny thing is, my shell is inside of a hidden hta shell so that's what you're really moving. Thanks VBScript.

[PrimalLove]

Nice code. But I'm new to this type of stuff so exactly why would this negate the need for Roll_in, Roll_out, Mouse_up?