The Lazarus backend interface unit is as follows but still unfinished:
----------------------------------------
unit backend;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, stdctrls;
procedure Backend_Save(essid, pw: string);
procedure Backend_Save_Connect(essid, pw: string);
function Backend_Query_Connect(connection: string; var pw: string): boolean;
function Backend_Delete_Connect(essid: string): boolean;
function Backend_Connection_Connect(essid: string): boolean;
function Backend_Disconnect_Active_Connection: boolean;
procedure Backend_Scan(aListBox: TListBox);
procedure Backend_Load_Existing(aListBox: TListBox);
implementation
const
opSave = 0;
opSaveConnect = 1;
opQueryConnect = 2;
opDeleteConnect = 3;
opConnectionConnect = 4;
opDisconnectActiveConnection = 5;
opScan = 6;
opLoadExisting = 7;
procedure Backend_Save(essid, pw: string);
begin
// backend opSave essid pw
end;
procedure Backend_Save_Connect(essid, pw: string);
begin
// backend opSaveConnect essid pw
end;
function Backend_Query_Connect(connection: string; var pw:string): boolean;
begin
// backend opQueryConnect essid pw
end;
function Backend_Delete_Connect(essid: string): boolean;
begin
// backend opDeleteConnect essid
result := true;
end;
function Backend_Connection_Connect(essid: string): boolean;
begin
// backend opConnectionConnect essid
end;
function Backend_Disconnect_Active_Connection: boolean;
begin
// backend opDisconnectActiveConnection
end;
procedure Backend_Scan(aListBox: TListBox);
begin
// backend opScan stringlist
end;
procedure Backend_Load_Existing(aListBox: TListBox);
begin
// backend opLoadExisting stringlist
end;
end.
---------------------------------------------
On 17/08/2015, Edward Bartolo <edb...@gmail.com> wrote:
> The Progress of My Coding Till Now:
>
> I am attaching two images of the GUI's main window and the only
> dialog. The GUI is programmed in Lazarus Pascal.
>
> The backend is in C. The code till now, although it doesn't do anything
> useful.
> ----------------------------------------------
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <unistd.h>
>
>
> using namespace std;
>
>
> #define opSave 0
> #define opSaveConnect 1
> #define opQueryConnect 2
> #define opDeleteConnect 3
> #define opConnectionConnect 4
> #define opDisconnectActiveConnection 5
> #define opScan 6
> #define opLoadExisting 7
>
> /*
> 1) Glib::spawn_sync instead of a pipe stream, provides a slot.
> 2) cmd trying to call an inexistent command still returns a valid pointer!
> verify cmd exists before calling exec
> */
>
> inline bool file_exists(char* name) {
> return (access(name, F_OK) != -1);
> }
>
>
> int exec(const char* cmd, char* out)
> {
> const int buf_size = 128;
>
> FILE * pipe = popen(cmd, "r");
> char buffer[buf_size];
> while(!feof(pipe)) {
> if(fgets(buffer, buf_size, pipe) != NULL)
> {
> if (out != NULL)
> strcat(out, buffer);
> else strcpy(out, buffer);
> }
> }
>
> return pclose(pipe);
> }
>
> int main(int argc, char *argv[])
> {
> char *out = 0;
> int switch_item = -1;
> if (argc > 1) switch_item = atoi(argv[1]);
>
> switch (switch_item) {
> case opSave:
> //saveFile(argv[2], argv[3]);
> exec("cat /etc/network/interfaces", out);
> //out[0] = ' ';
> printf(out);
>
> return 0;
>
> case opSaveConnect:
> //saveFile(argv[2], argv[3]);
> //Connect(argv[2]);
> return 0;
>
> case opQueryConnect:
>
> return 0;
>
> case opDeleteConnect:
>
> break;
>
> case opConnectionConnect:
>
> break;
>
> case opDisconnectActiveConnection:
>
> break;
>
> case opScan:
>
> break;
>
> case opLoadExisting:
>
> return 0;
> }
>
> return -1; // parameter not in range
> }
> ----------------------------------------------------------------
>
>
> On 17/08/2015, Rainer Weikusat <rainerweiku...@virginmedia.com> wrote:
>> James Powell <james4...@hotmail.com> writes:
>>> While there are packages that can be invisible and unintrusive into
>>> the system, there are some that cannot.
>>>
>>> The problem is responsibility.
>>>
>>> Who wants to remain responsible for boot scripts? Upstream or vendor?
>>>
>>> Who wants responsibility for providing interoperability between
>>> projects? Upstream or downstream bazaar?
>>>
>>> Who wants responsibility for the userland? Upstream or the downstream
>>> bazaar?
>>
>> It's possible to frame this in more technical terms: Who'll end up doing
>> system integration, system integrators or application developers? The
>> answer should (hopefully) be obvious.
>> _______________________________________________
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
