Programmers !

[CF Mark]

Well CrystalControl V2 is now getting a fair amount of time spent on it.

It will be in two parts, a NT Service (does all the hard work), and a GUI which will be used for configuration.

The NT Service is being written first for obvious reasons.
It will use DLLs for its funtions like getting data, writing to LCDs and interfacing with keypads.

Im going to make the source code for a sample "data" DLL available so people can then write thier own.

Now who would be interested in writing such DLLs?

It would be good to get poeple writing some ASAP as itll then give me some feedback on how well you guys think the whole DLL system ive come up with will work.
Its a rather complex system, but i think itll allow the new CC to do pretty much anything.

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[Americanfreak]

if i was smart enough to write DLL's I would.....

I'm just an end user.........

 

[Beast SS]

.DDL

I might be interested given the time. What are the language/IDE preferences, if any?

 

[CF Mark]

Re: .DDL

What are the language/IDE preferences, if any?

None. How you distribute your DLL is up to you.

Im writing CC in BCB V5, but theres no reason why DLLs created in any other IDE/Language shouldnt work.

 

[Beast SS]

I spent a couple of very fun years doing C++ and RAD using BCB 3 and BCB 5. I learned my ADO there. Too bad I don't have a copy at home. I will use Microsloth Visual...

 

[nherc]

Where can I get the API/dll samples?

I'm looking to output some information to my 634 from my Home Theater PC which runs some DVD Changer software, a video scaler and other fun stuffs.

 

[Draw6]

I suppose I should have read this post before my comments in the other thread (Requested features) dated today.

See that.

 

[CF Mark]

The version of CrystalControl that intorduces DLL use will not use the current ~tag~ system.
It will instead use an ID system. The idea is that the CrystalControl asks for data for a specific ID number, the DLL then passes the data for that ID number back to CrystalControl using a simple structure.
The GUI will save settings (ID nums) to a INI file, and the DLLs will have thier own INI files with matching IDs.

Hope that makes sense.

ATM im trying to work out the best way to handle custom charaters.
Any ideas?

 

[Draw6]

Are the DLLs going to take numbers or strings, passing integers or char* for parameters? The DLL should also be returning a string list containing the names (ID number) so they can be made available to the "Screens Editor".

I'd like to get the source template for that as soon as you're that far along, and ready for us to help.

The best way to handle custom characters would be a seperate character generator app that writes to INI files. and access these masterpieces again, from CC by way of ???

Something like this might work:

saves custom character

if(Edit1->Text != "")
{
char custchar[8] = {0,0,0,0,0,0,0,0};
//read matrix data from editor function elsewhere
//sends a parameter contaning custchar[]
//I'll just make it up for this example
custchar[0] = 0;
custchar[1] = 31;
custchar[2] = 17;
custchar[3] = 17;
custchar[4] = 17;
custchar[5] = 31;
custchar[6] = 0;
custchar[7] = 0;
Edit1->Text = "box";
TIniFile *CharsINI = new TIniFile(ExtractFilePath(Application->ExeName)+ "chars.cfg");
CharsINI->WriteInteger(Edit1->Text, "line0",custchar[0]);
CharsINI->WriteInteger(Edit1->Text, "line1",custchar[1]);
CharsINI->WriteInteger(Edit1->Text, "line2",custchar[2]);
CharsINI->WriteInteger(Edit1->Text, "line3",custchar[3]);
CharsINI->WriteInteger(Edit1->Text, "line4",custchar[4]);
CharsINI->WriteInteger(Edit1->Text, "line5",custchar[5]);
CharsINI->WriteInteger(Edit1->Text, "line6",custchar[6]);
CharsINI->WriteInteger(Edit1->Text, "line7",custchar[7]);
CharsINI->ReadSections(ListBox1->Items);//reload listbox
delete CharsINI;
}

I didn't create eight custom characters. But I did name it.
The INI file:
[box]
line0=0
line1=31
line2=17
line3=17
line4=17
line5=31
line6=0
line7=0


loads custom character within CC, I dunno? Dbl-clk a listbox, send *aname containing the word "box" from the INI file section name

void TFormX::Whatever(AnsiString *aname)
{
char custchar[8] = {0,0,0,0,0,0,0,0};
TIniFile *CharsINI = new TIniFile(ExtractFilePath(Application->ExeName)+ "chars.cfg");
//using chars.cfg as the INI filename
custchar[0] = CharsINI->ReadInteger(aname, "line0", 0);
custchar[1] = CharsINI->ReadInteger(aname, "line1", 0);
custchar[2] = CharsINI->ReadInteger(aname, "line2", 0);
custchar[3] = CharsINI->ReadInteger(aname, "line3", 0);
custchar[4] = CharsINI->ReadInteger(aname", "line4", 0);
custchar[5] = CharsINI->ReadInteger(aname, "line5", 0);
custchar[6] = CharsINI->ReadInteger(aname, "line6", 0);
custchar[7] = CharsINI->ReadInteger(aname, "line7", 0);

//sorry by I'm using LCDriver in this code to output
//you have it direct to the port yourself
lcdSetCustomChar(0, custchar);
lcdSendCharacter('\000');
}

I think you could manage unlimited characters this way - as long as the names are unique.

 

[Draw6]

Yikes! 64 different bits per line? 8 lines per character? Thats an aweful looking function thats gotta write that char[8] variable

something like set six bits true/false:

int i = GetCharLine(0,1,0,0,0,1); // =17
custchar[3] = i;
-----
int TForm::GetCharLine(bool a, bool b, bool c, bool d, bool e, bool f)
{
//jeex = 64 test posibilities
if(!a && !b && !c && !d && !e && !f) {return 0;}
if(!a && !b && !c && !d && !e && f) {return 1;}
...
...
//long list
...
if(a && b && c && d && e && f) {return 63;}
}

Good luck to the guy who's writing the editor.

 

[CF Mark]

The DLL passign stuct is as simple as this:

typedef struct
{
DWORD id;
char text[MAXROWLEN];
double num;
datatype type;
BYTE text_length;
BYTE error;
} data_data;

The service will pass the id to the DLL, where it will work out what is needed to be returned and fill the appropriate vars.
If its a number though, both "num" and "text" will be filled. This way the DLL determines how the number should be formatted on the LCD if its to be displayed as text, and as a number if its to be used as a bargraph.

Creating, saving, etc of the custom chars isnt a problem.
What im trying to work out is how to let DLLs send custom chars to the service. Eg, how does the service work out what custom chars from each DLL is used (only 8 avaliable remeber) per screen.
Code isnt a problem... i need a stratagy for handling this

 

[Draw6]

Only eight at a time - with each screen, the custom char set can change. So then it should be up to the screen editor to detect and limit how many custom characters can be show per screen. The existance of countless custom characters shouldn't hinder the implementation. Just keep track of how many (different) are used at one screenful.

 

[CF Mark]

The GUI isnt ging to be fun to write

So you think i should just allow the passing of up to 8 custom chars with the above structure?
As soon as 8 custom chars on one screen is used, ignore any new ones from other DLLs?

 

[Draw6]

Having just experimented with sending more than 8 diff custom chars to the same screen .... not a pretty sight.....

That sounds like the best idea, Just fire an error MessageDlg when the screen editor hits 8.

In the struct, should you add a flag var to tell the application that char text[MAXROWLEN] contains custom character data? Might help tell it where to go when it returns.

As you might have guessed, I'm also writing a similar application. Only mine is for educational purposes - probably not a public release. So I like sharing ideas with you.

I'm also an LCD fanatic.

 

[CF Mark]

So somthing like:

typedef struct
{
bool used[8]; //flags which custom chars are used
BYTE rows[8][8]; //rows for 8 custom chars
} data_char;

typedef struct 
{ 
DWORD id; 
char text[MAXROWLEN]; 
double num; 
datatype type; 
BYTE text_length; 
BYTE error; 
data_char chars;
} data_data;

Requires more thought.
What happens if a DLL wants to use the same chars more than once.

 

[Draw6]

Maybe the DLL needs another export function. One like
char GetCustomChar() and keep this seperate from the other function. Sounds easier to maintain.

Once you load a char to \128 - \135 in cc, the unit isn't going to care what screens use it or where. But it's going to have to look it up every time it's displayed, in case another screen loaded one from a different DLL to an existing assignment.

I saw the screen shot for the "Boot Screen Configuration". Are you going to duplicate this effort in a seperate character generator, or move that part to a "one for all" window?

 

[CF Mark]

I have no idea what im going to do about a char editor yet. That comes later, after the GUI.

Hmm, ill come up with some way of managing custom chars.

 

[rifter]

being able to edit every character on the chip would be really cool. then you could have different fonts.

 

[Draw6]

being able to edit every character on the chip would be really cool. then you could have different fonts.

Everything past the first 32 - the control characters I mean.

Prolly have a lot of complaints about empty eeproms if the kids get hold of it.

I'm wondering past the serial 4 line text device isle and in front of the graphic lcd case. How about a version of CrystalControl that writes to graphic 240x320 as well. I understand those have programmable fontz.

That piece of software would be worth a good chunk of casemod cash. And well spent. Heck, I'll take three right now. Backorder me - sign where?.

 

[CF Mark]

being able to edit every character on the chip would be really cool. then you could have different fonts.

Cant be done.
HD44780 and the 63x displays can only have 8 custom characters.
The rest cannot be changed.