Customize Calendar Add-In

[Blake]

I suppose this should be aimed at Jerry? Anyone with ideas feel free to chime in.

I have the calendar add-in. Some situations have presented themselves.

First, my source date is in one of two fields. I have scheduled and actual dates, and the scheduled date should be used unless the actual date is present. I know I can handle this by adding a calculated date field that has either the scheduled or actual, depending.

Second, I actually have two source dates. A start and an end. I'd like to display both, but I don't see how that's possible.

Finally, what I'd really like to do is add a colored line (or lines) from the start date to the end date, for scheduling. So that if Joe has a job from the 1st through the 8th and from the 17th through the 30th, it's immediately obvious that he's free from the 9th to the 16th.

Ideally, there could be more than one line, in case the user wants to see Joe, Fred, Bob and Dave all at once.

In other environments (or even given working ActiveX), I would look for a calendar control tht had source available so I could mod it. Or maybe I could figure out how the add-in was made, were there docs on that.

As it is, though, I'm stumped.

[JerryBrightbill]

RE: Customize Calendar Add-In

Blake

As in any design, the final version is a compromise. I tried to accomodate as many different scenarios as possible, but it was not possible to accomodate every use imagined. A very few people expressed a desire to link two dates, however, after examining the process, it was obvious there were too many variables to produce any solution that could be applied in a generic manner. Each situation was unique. The only simple solution was two calendars. Currently, you can open two calendars for the same table at the same time.

The idea of color coding was considered, but again, the process of adding a color expression became too complex for a generic solution. There are too many different ways a date can be linked to a calendar.

Both situations could be accomodated in a one off custom solution, but each solution would be unique for each table configuration etc. In fact, both were in the original design specifications, but a workable solution that could be applied to any table configuration wasn't possible.

There are no plans to offer additional options beyond those currently available.

Jerry

[Blake]

RE: Customize Calendar Add-In

Jerry,

I can certainly respect the decisions that had to be made. And, lest anyone get the wrong idea, this is a solid add-in. I like it very much.

But that don't feed the baby. (Er, shoe the baby. Er, do whatever it is that the baby needs done.)

I'm more pointing out the absence of any way to extend or customize add-ins. They'll either handle your needs, or they won't. You either start anew, or curb your needs. That's got to make your job as an add-in maker harder, too, since you're stuck making tougher decisions than just providing the odd hook for people with "unusual needs". I do hope A6 provides a little more in the way of extensibility.

Anyway, do you have any resources you can for building add-ins you can make public? I haven't really found much on-line, just one article that I can recall.

===Blake===

[JerryBrightbill]

RE: Customize Calendar Add-In

Blake

An addin is just a collection of scripts or functions compiled into an aex with help files and other additions. When the addin is loaded in the addins_installed subfolder under the a5 program folder, the scripts and functions become available to any database running in A5. That is basically the definition of an addin. Creating aex files is covered in the help files, as are all of the other actions. All of the screens, actions, etc are coded just like any script. To make a change requires changing the basic code, since you are just modifying a script code.

The mechanics of creating your own addin is easy and straight forward. Writing scripts and functions for generic use and trapping all possibilites is not so easy.

Unless the actual code is visible to the end user, it can't be modified unless the developer allows a certain level of customization in the code. Typically, you wouldn't allow an end user access to the underlying code as the potential for disaster is huge. For example, the calendar has over 7000 lines of code and even a small change can have huge effects.

Jerry

[Blake]

RE: Customize Calendar Add-In

Jerry,

"i"Creating aex files is covered in the help files, as are all of the other actions."/i"

Is there a section for handling startup and/or shutdown code? Or do you just include an autoexec function in your AEX to do things like add the context menus?

Also, how do you keep add-ins from conflicting? You've used the Calendar_* for stuff, what's to keep another add-in from using the same name or same variable?

Also, since it's all functions and scripts, etc., that means it can't be a component that you include as part of a form, I take it. (The component palette doesn't appear to be extensible in any form, anyway.)

"i"Typically, you wouldn't allow an end user access to the underlying code as the potential for disaster is ...."/i"

Let me introduce you to my pal, object-oriented, event-driven, component-based code. :-)

Seriously, I know how hard this is to do. My first meaty A5 project was an attempt to make a reusable, extensible component that we could use on all our forms. It works, and will help us maintain our app--and it might even be marginally easier to set up than re-writing the code for each form--but it's not pretty.

Let me ask you one more thing (and I appreciate your patience with all this): Would it be feasible to put something like, say, the sample clock into an add-in? The user would have to link the OnDraw, OnSize and OnTimer events to scripts in the add-in, and for other controls, he'd probably also want to link the OnKey, OnMouse, and other events as well.

The thing that I wonder about (and if I get a moment, I'll try it myself) is whether the various contexts would be accessible. The A_USER and table variables in particular.

If it could work, it would at least be possible to provide some kind of extensibility.

[JerryBrightbill]

RE: Customize Calendar Add-In

Blake

To answer your questions;

"Is there a section for handling startup and/or shutdown code? Or do you just include an autoexec function in your AEX to do things like add the context menus?"

There is currently no obvious way to handle startup and shutdown code. You can put an autoexec in the aex, but it will be superceeded by a local autoexec. After some experimentation, it appears code runs in this sequence. Local scripts, scripts in attached libraries, and then scripts in a global addin aex.

"Also, how do you keep add-ins from conflicting? You've used the Calendar_* for stuff, what's to keep another add-in from using the same name or same variable?"

You can't. The trick is to use odd variable names, script names, and function names unlikely to be used by someone else. For example, never start a function name with A5_ as this is reserved for Alpha functions. If you have a local variable in the script with the same name as a user defined global variable, you will have some "issues"

"Also, since it's all functions and scripts, etc., that means it can't be a component that you include as part of a form, I take it. (The component palette doesn't appear to be extensible in any form, anyway.)"

If you are thinking of adding functionality to a form like a clock control etc, that is a different issue. You can add anything that can be added by action scripting - a script, a function, specified code, but not a new object type. The exception would be if you had an ActiveX control, you can add that in some cases.

In a sense, you could add something like a clock control, since a clock is just a series of scripts on a user control. Each of the scripts could be prebuilt and saved in an aex. You would still have to call each script from each event on the control as needed, but you wouldn't have to write the code everytime. Of course, you could also just save the code in the code library and paste as needed, which is just as easy. Depending on how you look at it, the code in the code library is, in effect, an addin. You can choose any saved code and "add" it to any code location.

An addin is just something "added" to a database. It could very easily be a form based on a generic table. In that case, you just attach the table to the database. For example, you mention the sample clock. I assume you are referring to the analog clock in the help files. I have build one of those on a form that is attached to a dummy table with one record. I just attach the table to a database to have the clock available. The calendar addin also has a digital clock included and there is code in the archive to put a digital clock in a toolbar. There is no reason you couldn't build an analog clock in xdialog, since it would just be a bitmap that redraws ever second.

Jerry

[CALocklin]

RE: Customize Calendar Add-In

If you have a local variable in the script with the same name as a user defined global variable, you will have some "issues"

This is one reason for making sure all variables in generic scripts and functions are DIMmed. Although I haven't tested it recently, if a script/function uses the same variable name as a Global variable but the variable is DIMmed in the script (e.g., DIM MyVar as C), then there shouldn't be any conflict. Of course, some amount of care is required so you don't confuse yourself in the process.

To make sure everything is DIMmed, click Code on the toolbar and select "Find Undimmed Vars" near the bottom of the drop-down list.

[Blake]

RE: Customize Calendar Add-In

"There is currently no obvious way to handle startup and shutdown code. You can put an autoexec in the aex, but it will be superceeded by a local autoexec. After some experimentation, it appears code runs in this sequence. Local scripts, scripts in attached libraries, and then scripts in a global addin aex."

What is it in the add-ins that modifies A5's menus? There must be something executed, mustn't there?

"You can't."

Sorta what I figured.

"If you are thinking of adding functionality to a form like a clock control etc, that is a different issue. You can add anything that can be added by action scripting - a script, a function, specified code, but not a new object type. The exception would be if you had an ActiveX control, you can add that in some cases. "

Said cases not really documented, AFAIK. Even the simplest of my ActiveX controls do not work in A5. Actually, no one's do, at least on my machines, but at least some fraction are at least recognized by A5 where mine are not.

"In a sense, you could add something like a clock control, since a clock is just a series of scripts on a user control. Each of the scripts could be prebuilt and saved in an aex. You would still have to call each script from each event on the control as needed, but you wouldn't have to write the code everytime. "

Right. That's what I was getting at.

"Of course, you could also just save the code in the code library and paste as needed, which is just as easy. Depending on how you look at it, the code in the code library is, in effect, an addin. You can choose any saved code and "add" it to any code location. "

Just as easy to add, but a maintenance nightmare. The reason I set up the universal navigation control wasn't because it was easy, but because I didn't want 100 copies of "nearly identical" code to maintain when suddenly someone said, "Oh, yeah, let's add =THIS= to the mix."

"An addin is just something "added" to a database. It could very easily be a form based on a generic table. In that case, you just attach the table to the database. For example, you mention the sample clock. I assume you are referring to the analog clock in the help files. I have build one of those on a form that is attached to a dummy table with one record. I just attach the table to a database to have the clock available."

Yes. That's sort of how I did the generic UI component.

"The calendar addin also has a digital clock included and there is code in the archive to put a digital clock in a toolbar. There is no reason you couldn't build an analog clock in xdialog, since it would just be a bitmap that redraws ever second."

But unless I can embed an xdialog on a form, I don't want to do that. I know I can do lots of stuff with xdialog--I'm right in the middle of using it to generate browses based on user-defined specs--but it's a whole 'nother world.

Like many things in A5, it's an island unto itself.

[JerryBrightbill]

RE: Customize Calendar Add-In

Blake

We are talking apples and oranges. Both are fruit, but very different. From your post, it appears you are thinking of an addin as an object addin, like an activeX control. Alpha has very limited support for ActiveX and does not have a method to create your own object addin. Contrary to what Microsoft cliams, ActiveX is not universal and support varies depending on what is loaded on an individual computer.

Addins in Alpha are mainly code library addins that are better integrated into the program. They should probably be considered functional addins, not object addins. While the addin may create an object, like the calendar, that object can not be attached directly to another object like a form. It can be "called" from the form as a separate window. At this point, you can not embed xdialog on a form. An addin may have a dedicated table with objects, but again, it is just like attaching another table to a database.

The method to create an Alpha addin has a number of parts. A series of scripts or functions are compiled into an aex. The aex is added to the addins_installed program folder. Then a control_panel_addin can be built to show various functions on the addin menu. This does not happen automatically and is just menu code like a popup menu. You can also write code to have it show in Action Scripting, but this is more involved.

Jerry