This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - jwalker
16
« on: November 20, 2013, 12:05:44 pm »
So I upgraded from 8.1 preview to 8.1 and am working on getting a new license, should be back up and developing soon.
17
« on: October 16, 2013, 10:24:02 pm »
Here is a partial example program that I was working on for physics, but unfortunately never finished before the test  It displays several important things that can be done with WZ such as encapsulating forms with all of their objects into classes and event binding. It also shows my bad graphics drawing abilities
18
« on: September 28, 2013, 11:22:27 pm »
With this update, I corrected the call system on the console.
19
« on: September 26, 2013, 08:20:36 am »
Sorry for my silence for the last month, I just started college and it has been hectic! I haven't gotten a lot done, but I have been working on this project periodically.
20
« on: August 16, 2013, 09:43:11 am »
Basically when you press the enter key while using the console, it packages everything sent into a table. In this case the third value in the table will be the function name, and the fourth value in the table will be the other arguments.
for i = 5, #bt do
bt[4] = bt[4]..", "..bt[i]
end
local fCall = assert(loadstring(bt[3].."("..bt[4]..")"))
a, b = fCall()
self:addHistoryEntry("Returned: "..tostring(a).." and "..tostring(b))
21
« on: August 15, 2013, 12:47:34 pm »
I'm ready to say that there is a bug in TI's Lua. When you call a function created by loadstring, you are supposed to get any of the values returned by the function. That is not happening.
22
« on: August 12, 2013, 09:09:13 pm »
Is there a way to get the value returned by a chunk loaded with loadstring?
I have tried:
pcall
xpcall
I also tried to set the environment with setfenv, but to no avail.
23
« on: August 10, 2013, 08:12:43 pm »
I've seen a Surface IRL. It is more a PC with a detachable keyboard and a touchscreen than a tablet. I have one of these and this is true, it is more of a pc than a tablet.
24
« on: August 08, 2013, 12:43:47 pm »
I've been working on the statusbar recently, and I have made significant progress. It should be finished or almost finished by the end of the day.
25
« on: August 07, 2013, 01:26:51 pm »
That would be great. I am going to make several test applications in the near future, to release with WZ 2.5 in order to demonstrate several of the things that can be done with it.
Also I noticed that on Windows 8.1 the Nspire software dosent close properly, the window closes but it still runs in the background and wont let you open a new instance of it untill you kill the previous process.
26
« on: August 06, 2013, 09:20:56 pm »
Does anyone know a good way to figure out an index of a string based on a pixel value?
27
« on: August 06, 2013, 01:58:17 am »
Here is a kind of test application. It uses several of the new concepts presented in the new WZ, such as function binding and that page control. I also added something special. I wrote it just today. I am introducing the new styled dialog. Currently there are three styles: OK, OK_CANCEL, and OK_CANCEL_TRYAGAIN. All you have to do is provide the callback. There is currently 3 things passed as arguments to your callback function:
callback(code, buttonObj, buttonObj_Parent).
the code is a 1, 2, or 3; They represent the button that were pressed.
I am not done with them, design wise. For functional purposes they are releasable.
28
« on: August 04, 2013, 10:54:40 pm »
Yes, as in arguments.
29
« on: August 04, 2013, 10:44:07 pm »
Your origional code would work except when you look at your constructor, your parameters must be equil to your variable.
ex:
function Units:init(plr, x, y, str, move, opt) --these are not your self. variables, they are just values that are passed when it is called.
self.plr = plr --Notice how you are setting the self. variable to the variable passed in the constructor.
self.x = x
self.y = y
self.str = str
self.move = move
self.opt = opt
end
When you used uplr instead of the plr you passed in your constructor, you essentialy are setting self.plr to nil because uplr does not exist.
30
« on: August 04, 2013, 09:53:59 pm »
So, like I said here is another upload.
There is one major change. I used a modified version of the event distributer from inspired-lua and replaced all of the on events. Also, if you ever look back a couple of pages on this topic, you will notice an attached file that is called WZGUILIB_EV. The purpose of that file was to be able to take a WZ event, such as a window closing, and be able to run your own code in a callback function. This implements something similar, just with out all of the coding overhead. It is very simple,
form_or_dialog_name:bindEvent(string event, function callback). There is a catch though; at the end of your function before you return you must call the original handler code. This is possible because the first argument passed to your callback is the window that is supposed to receive the function. so if you had a form named winForm and a callback called closeCallback you can do this:
winform:bindEvent("close", closeCallback)
You closeCallback function then looks like this:
function closeCallback(window)
print("Caught the close event")
form.close(window)
end
This takes away a lot of coding and excess code from the original way that it was supposed to be done.
|
Show Posts
