Redirect API?

local termWidth, termHeight = term.getSize()
local selectedItem = 1
local onMainMenu = true

function Choice1()
term.clear()
term.setCursorPos(1,1)
print("Changeme to program name1")
sleep(1)
shell.run("Changeme to program name1")
end
function Choice2()
term.clear()
term.setCursorPos(1,1)
print("Send Mail")
sleep(1)
shell.run("SendMail")
end
function Choice3()
term.clear()
term.setCursorPos(1,1)
print("Read Mail")
sleep(1)
shell.run("ReadMail")
end
function Exit()
onMainMenu = false
end
mainMenu = {
[1] = { text = "Changeme to program name", handler = Choice1 },
[2] = { text = "Send Mail", handler = Choice2 },
[3] = { text = "ReadMail", handler = Choice3 },
[4] = { text = "Exit", handler = Exit }
}
function printMenu( menu )
for i=1,#menu do
if i == selectedItem then
print(">> "..menu[i].text)
else
print(" "..menu[i].text)
end
end
end
function onKeyPressed( key, menu )
if key == keys.enter then
onItemSelected(menu)
elseif key == keys.up then
if selectedItem > 1 then
selectedItem = selectedItem - 1
end
elseif key == keys.down then
if selectedItem < #menu then
selectedItem = selectedItem + 1
end
end
end
function onItemSelected( menu )
menu[selectedItem].handler()
end
function main()
while onMainMenu do
term.clear()
term.setCursorPos(1,1)
printMenu(mainMenu)
event, key = os.pullEvent("key")
onKeyPressed(key,mainMenu)
end
end

SkyRamon, on 06 February 2014 - 12:33 PM said:

-Snip

parallel.WaitForAll(main)

SkyRamon, on 06 February 2014 - 05:50 PM said:

well after you lanched the program and its done you should get back to it automaticly.
otherwise write

parallel.WaitForAll(main)

at bottom of the main menu code

D3matt, on 06 February 2014 - 07:16 PM said:

You want to use the term AP to create a new term object that copies all of the term API functions except modified to create your menu bar at the top and write everything below it.

faketerm = {write = mytermAPI.write, clearLine = term.clearLine}
term.direct(faketerm)

Lyqyd, on 06 February 2014 - 10:11 PM said:

The term API in /rom/apis doesn't have anything interesting in it. You'll want to get the list of functions you need by either iterating term.native (1.58 and earlier) or iterating the table returned by term.native() (1.6beta and later).

local termObj = {
  clear = function()
	term.native.clear()
	term.setCursorPos(1,1)
	print("Awesome sauce")
  end
}

setmetatable(termObj, {__index = term.native})

term.redirect(termObj)

--# code that uses new term

term.restore()

local termObj = {
  clear = function()
	term.native().clear()
	term.setCursorPos(1,1)
	print("Awesome sauce")
  end
}

setmetatable(termObj, {__index = term.native()})

local previousTerm = term.redirect(termObj)

--# code that uses new term

term.redirect(previousTerm)

D3matt, on 07 February 2014 - 08:48 PM said:

I think it would be more effective and almost as easy to just write up a term clone.

Are there any servers you play on? I'd like to get on and chat and try and code something like this.

Symmetryc, on 10 February 2014 - 04:54 PM said:

I don't really understand what you're trying to accomplish. Are you trying to overlay a menu on top of a running program?

nutcase84, on 10 February 2014 - 05:17 PM said:

Symmetryc, on 10 February 2014 - 04:54 PM said:

I don't really understand what you're trying to accomplish. Are you trying to overlay a menu on top of a running program?

Yes!

Symmetryc, on 10 February 2014 - 06:48 PM said:

nutcase84, on 10 February 2014 - 05:17 PM said:

Symmetryc, on 10 February 2014 - 04:54 PM said:

I don't really understand what you're trying to accomplish. Are you trying to overlay a menu on top of a running program?

Yes!

Are you sure you don't just want to adjust the size and position of the program so that it fits in the space below the menu, rather than sit on top of the program (obstructing part of it)?

Bomb Bloke, on 11 February 2014 - 08:12 PM said:

That doesn't really answer his question…

There are two ways to go about this. One is to have your API ignore any attempts by the running script to write stuff to the first line of the screen. This is fairly simple, but has a big downside in that you simply won't see the first line such scripts attempt to write - it'll be cropped out of view.

The other is to have your API capture ANY writes by the running script, and move them down one line. The upside is that the first line no longer gets cropped out of view - it's now just a line lower. The downside is that you've gotta rewrite most of the term API to pull it off. Optionally, you'd also report a smaller screen size to the scripts you run - this will allow those scripts which feel they "need" the whole display to throw up appropriate errors.

He's wondering which of these approaches you intend to take with your API.

Either way, you'll need to capture mouse input as well… The first method requires you to prevent the running script from "seeing" clicks in the top row. The second method requires you to report all clicks (except those to the top row) as being a line lower then they were actually located at. Either way you need to handle clicks to the menu bar itself.

While you could just rig co-routines to re-draw the menu bar whenever there's a chance, you never know how often you'll get those chances, let alone whether or not it needs to be redrawn. Expect a lot of flickering and an overall performance hit if you take that approach.

_G.backup = {
  term = {
	setCursorPos = _G.term.setCursorPos,
	getSize = _G.term.getSize
  }
  os = {
	pullEventRaw = _G.os.pullEventRaw
  }
}
_G.term.setCursorPos = function(x,y)
  _G.backup.term.setCursorPos(x,math.max(2,y))
end
_G.term.getSize = function()
  local x,y = _G.term.getSize()
  return x,y-1
end
_G.os.pullEventRaw = function(filter)
	local tEvent = {_G.backup.os.pullEvent(filter)}
	if tEvent[1] == "mouse_click" then
	  tEvent[3] = tEvent[3]-1
	  --menu code here
	end
  return unpack(tEvent)
end

os.loadAPI"redir"
--this is how to use it on a running program
redir.redirect(getfenv())
-- this is how to use it on a program you wish to run
local prog = loadfile"/progPath"
redir.redirect(prog)
prog()

CometWolf, on 12 February 2014 - 10:51 AM said:

A really quick and easy way of doing this would be overwriting the setCursorPos, getSize and pullEvent functions. This does however mean that you'll have to use the backup methods.

_G.backup = {
  term = {
	setCursorPos = _G.term.setCursorPos,
	getSize = _G.term.getSize
  }
  os = {
	pullEventRaw = _G.os.pullEventRaw
  }
}
_G.term.setCursorPos = function(x,y)
  _G.backup.term.setCursorPos(x,math.max(2,y))
end
_G.term.getSize = function()
  local x,y = _G.term.getSize()
  return x,y-1
end
_G.os.pullEventRaw = function(filter)
	local tEvent = {_G.backup.os.pullEvent(filter)}
	if tEvent[1] == "mouse_click" then
	  tEvent[3] = tEvent[3]-1
	  --menu code here
	end
  return unpack(tEvent)
end

The API way of doing this would require a bit more work. So here's a quick attempt i just threw together.
http://pastebin.com/FH3eB0t8

os.loadAPI"redir"
--this is how to use it on a running program
redir.redirect(getfenv())
-- this is how to use it on a program you wish to run
local prog = loadfile"/progPath"
redir.redirect(prog)
prog()

Do note however that both of these approaches require you to program your menu into them, because of how pullEvent works.

os.loadAPI"redir"
local program = loadFile"/programPath"
redir.redirect(program)
parallel.waitForAny(program,
  function()
	--menu code here
  end
)

CometWolf, on 12 February 2014 - 12:09 PM said:

Yeah i don't see why not. However, the original program wouldn't be closed and the menu would stop working, unless you use the API on the program that's loaded aswell. If you do that however, you'd end up with some slight recursion. I just realized there is a simple way to keep the menu code seperate from the API, using parallel.

os.loadAPI"redir"
local program = loadFile"/programPath"
redir.redirect(program)
parallel.waitForAny(program,
  function()
	--menu code here
  end
)

CometWolf, on 12 February 2014 - 10:51 AM said:

A really quick and easy way of doing this would be overwriting the setCursorPos, getSize and pullEvent functions. This does however mean that you'll have to use the backup methods.

CometWolf, on 12 February 2014 - 05:11 PM said:

and you can't pass an argument to the program either, as it does not use shell.run.

function os.run( _tEnv, _sPath, ... )
	local tArgs = { ... }
	local fnFile, err = loadfile( _sPath )
	if fnFile then
		local tEnv = _tEnv
		setmetatable( tEnv, { __index = _G } )
		setfenv( fnFile, tEnv )
		local ok, err = pcall( function()
		 fnFile( unpack( tArgs ) )
		end )
		if not ok then
		 if err and err ~= "" then
		printError( err )
			end
		 return false
		end
		return true
	end
	if err and err ~= "" then
		printError( err )
		printError( "bar" )
	end
	return false
end

Symmetryc, on 12 February 2014 - 08:01 PM said:

So that you don't have to mess around with restoring or possible screw ups or anything since it's all controlled.

theoriginalbit, on 12 February 2014 - 06:20 PM said:

you don't have to… as I've said already, you can make a term object and just redirect to it, its what I do in CCTicTacToe to easier support normal and advanced computers.

CometWolf, on 13 February 2014 - 12:14 AM said:

You're missing the point, that was a suggestion for a quick and easy way to do it. Also as far as i know, that wouldn't allow us to change os.pullEvent.

CometWolf, on 13 February 2014 - 12:14 AM said:

Symmetryc, on 12 February 2014 - 08:01 PM said:

So that you don't have to mess around with restoring or possible screw ups or anything since it's all controlled.

This is exactly what the api i threw together does >.>

local firewolfLocation = "/" .. shell.getRunningProgram()

CometWolf, on 13 February 2014 - 09:22 AM said:

Ah yes…

local firewolfLocation = "/" .. shell.getRunningProgram()

Any program loaded with dofile/loadfile won't have acess to the shell table, and thus not it's functions either. Lemme get right on that, since i've been meaning to implement the argument possibility bit suggested i'll just do them both. Wasn't planning on putting much work into this, but it seems it could come in handy, so i might aswell.

local redir = dofile"/redir" -- this will return the redirect function
redir(x1,y1,x2,y2,(filePath or function or table),arguments)
--x1 is where the left of the screen should be
--y1 is where the top of the screen should be
--x2 is where the right of the screen should be
--y2 is where the bottom of the screen should be
--filePath should be self-explainatory
--as should arguments

local redir = dofile"/redir"
parallel.waitForAny(
  function()
    redir(1,2,term.getSize(),filePath)
  end,
  function()
    --menu code here
  end
)

CometWolf, on 13 February 2014 - 06:05 AM said:

It's just one variable, the redirect table. I wasn't sure if indexing to a local table from a program that dosen't have acess to it would work or not.

-- File 1
local t = {"hi"}
return t
-- File 2
local file_1 = dofile("file_1")
print(file_1[1]) --> "hi"