Support for 3rdParty Activex/COM in v10?

[gcoulthard]

Just wondering if anyone has heard anything about improvements in the way that v.10 handles activeX and COM controls?

I have the Codejock UI Suite and I'd like to implement some of the Ribbon and Calendar controls.

Thanks for any insights,
Glen

[rmcgaffic]

Re: Support for 3rdParty Activex/COM in v10?

Glen,

I also bought the CodeJock controls. There are so many events that A5V9 doesn't deal with -- or at least that has been my experience with the Xtreme CalendarPro Control.

Calendaring/scheduling is a way big gap in Alpha's functionality. The attempts at calendars/schedules built natively in Alpha are crude and amateurish in appearance -- maybe ok in the 80's, but definitely not today.

In my mind you can't build a serious Customer Relationship Management (CRM) applicaiton without both email and calendaring. Alpha provides a passable email (although it could stand a serious upgrading), but the lack of a calendar with get this -- drag and drop capability to move around appointments is a big, big deficiency.

In my opinion, that's why no one uses Alpha to develop CRM applications -- it's missing the calendaring tools and worse yet, it doesn't allow industry standard quality ActiveX controls like CodeJock's to work.

That's why I proposed earlier a clearing house list of controls that work with Alpha Five, because I have found so many that don't.

Bob McGaffic
Pittsburgh, PA

PS: (Thinking out loud) I wonder what Alpha would charge to replicate the very simple
CodeJock demo using Microsoft Access for the Xtreme Calendar Pro (including recurring appointments, etc) in Alpha Five? Have you tried it yet? So simple, so easy -- and for me thus far, impossible to get working in Alpha Five.

[gcoulthard]

Re: Support for 3rdParty Activex/COM in v10?

>> I wonder what Alpha would charge to replicate the very simple CodeJock demo using Microsoft Access for the Xtreme Calendar Pro.�

Yes, that would be wonderful. As a new user to Alpha Five, the one complaint I have (as you also articulated) is that the UI for end-users is very blah-1990s (to be nice). The applications I am creating need to be modeled after Office 2007, if I am to persuade any users to adopt.

While the Web-based Ajax stuff is great and all (and very impressive), isn't the bread+butter for most application developers still on the desktop? With Codejock's stuff, you could produce high-quality, appealing interfaces to access the strength of Alpha's backend, query, and reporting capabilities. It just makes sense from a developer's standpoint to not have to re-create the wheel. Maybe we'll get lucky with some improvements in v.10.

Glen

[Peter.Wayne]

Re: Support for 3rdParty Activex/COM in v10?

What part of the Codejock Calendar Control can't you get to work? I just downloaded the evaluation and it seems to work fine with A5. Admittedly I just put up an elementary calendar and used Alpha Five to switch from day view to week view to month view, but it works without a hitch, and I would imagine the other Codejock calendar methods should also work.

[NoeticCC]

Re: Support for 3rdParty Activex/COM in v10?

The applications I am creating need to be modeled after Office 2007, if I am to persuade any users to adopt.

Funny, while I agree with the wish for more modern UI, I have yet to meet an Office user who actually enjoys and prefers the "Ribbon" style menus....

[rmcgaffic]

Re: Support for 3rdParty Activex/COM in v10?

Peter,

I was also able to change the view of the CalendarControl to daily, work week, calendar week, and month. I got the time "ruler" to work fine too displaying 10 minute, 15 minute, 30 minute, and hourly intervals.

I placed two buttons on the form frmCalendar to open another form frmCalendarEvent.

1. Open the frmCalendarEvent using an object reference
2. Open the frmCalendarEvent using a window name

These buttons work just fine. But the trouble started when I tried to use the Double Click event.

I placed the code behind the buttons behind the Double Click event for the CalendarControl1 on frmCalendar.

When I double click on CalendarControl1, nothing happens -- other than the display of a message box that the double click even had been triggered.

Then something really strange happened.

I zipped my application for attachment to this thread. I extracted it just to double check it before sending. Guess what happened? The double click event fired and the frmCalendarEvent partially opened in dialog mode, but not the full screen mode as it should have. My computer froze and CPU usage was 100%.

I logged off and tried again. Then the double click event does not even attempt to open frmCalendarEvent.

Any ideas why this isn't working correctly?


Glen,

I have to agree with Andrea. Users can hide the Microsoft Ribbon, but they can't remove it and bring back the Alpha style pull down menus. I personally never upgraded to Office 2007 because of the ribbon. If you use a ribbon in your application, I hope you will not force your users to deal with a menu similar to the attached screenprint from a commerical product. Unless your application is fairly simple this icon driven approach runs out of steam quickly.

Bob McGaffic
Pittsburgh, PA

[JPFromtally]

Re: Support for 3rdParty Activex/COM in v10?

If v10 requires outside components like CodeJock for calendaring I will be very disappointed.

[Peter.Wayne]

Re: Support for 3rdParty Activex/COM in v10?

Bob,
Here's something I just threw together -- it responds to the Codejock Calendar's dblclick event. It doesn't do anything except give a message. The Codejock documentation is extensive and I don't find it particularly easy to understand how to do anything, but that's hardly Alpha's problem. It seems to me that A5 can respond to events in the Codejock calendar and can also set properties of the calendar. I'm not sure what else one can expect.

dim xcal as p
dim xcal.object as p
dim xcal.class as c="codejock.calendarcontrol.13.1.0"

xcal.events=<<%code%
function dblclick as v()
	ui_msg_box("xcal","dblclick")
end function 
%code%

dlgEvents=<<%code%
if a_dlg_button="init" then
    xcal.object.viewtype=xtpcalendardayview
    xcal.object.FullDateMode = .t.
	xcal.object.DayHeaderFormat = "Office %A -- %B %d, %Y   Week: %W"
end if
if a_dlg_button="month" then
    xcal.object.viewtype=xtpcalendarmonthview
end if
if a_dlg_button="week" then
    xcal.object.viewtype=xtpcalendarweekview
end if
if a_dlg_button="day" then    
    xcal.object.viewtype=xtpcalendardayview
end if
if a_dlg_button="Close" then
    ui_modeless_dlg_close(dlgTitle)
end if
%code%

dlgTitle="Calendar"
dlgText=<<%dlg%
{can_exit=Close}
{startup=init}
{stretch=width,height}
{activex=140,35xcal};
{stickto=left,bottom}
<Close> <Month view!month> <Week view!week> <Day view!day>;
%dlg%

ui_modeless_dlg_box(dlgTitle,dlgText,dlgEvents)

[rmcgaffic]

Re: Support for 3rdParty Activex/COM in v10?

Peter,

Thank you for sharing your code. Unfortunately, I am unable to replicate your results.

I tried the following:

1. Placed your code behind a button on my form
2. Placed your code behind my form's OnInit event.

Of course Alpha complains because the following are not defined as variables:
xtpcalendarmonthview
xtpcalendarweekview
xtpcalendardayview

So I defined them as N and the error messages disappear.

But the calendar control itself doesn't display.

I placed a CodeJock calendar control on my form and called it XCAL as per your code.

Clicking on your buttons on the Xdialog form does not change the calendar view on my base form.

I know I'm doing something wrong, but I'm not sure exactly what.

Can provide any additional details on what you did to get this work.

Again the issue isn't that the double click event doesn't work -- my form can open a msgbox("Double click event triggered") just fine.

The problem is that when the double click event includes code to open another form, for example a form for a calendar appointment, Alpha goes into a memory black hole. CPU usage jumps to 100% and my computer freezes.

Bob McGaffic
Pittsburgh

[Peter.Wayne]

Re: Support for 3rdParty Activex/COM in v10?

Hi, Bob.
Sorry, I just got in late tonight.
All I did was to run that code as an Xdialog from the code editor window. I did not put it on a form. I did not have to define the constants for xtpcalendarmonthview, etc. -- they were picked up by Alpha from the definition of the control, I believe. At least, the OLE object explorer knows their definitions, and I did not need to redefine them for the Xdialog to work. I have not been using ActiveX on forms, only in Xdialogs, as I'm not using many forms.

If you can't get the Xdialog to work as an Xdialog, then we have another issue. It may be that I have a different version of v9 than you do. I have a recent build that has a few bug fixes that may not have made it into general release but none of the bugs (that I reported, anyhow) have anything to do with activeX xdialogs.
So -- just copy the code as written to a script and run it. Let me know if that fails to work.
- Peter

[gmeredith17]

Re: Support for 3rdParty Activex/COM in v10?

If you can't get the Xdialog to work as an Xdialog

I'm a little confused. I thought the whole point of the activex control on the form toolbox is to be able to embed them on a form. What has this got to do with xdialog? (request for knowledge not a criticism)

[Peter.Wayne]

Re: Support for 3rdParty Activex/COM in v10?

I'm just trying to track down what doesn't work for Bob. I don't use forms in general. If the ActiveX control works in an Xdialog for Bob then we can go from there. It's easier to figure out what might be wrong if you remove extraneous issues, like whatever else might be on his form.

[jkletrovets]

Re: Support for 3rdParty Activex/COM in v10?

Hi Peter...

Not to hijack this thread but one quick question.....why are you using xdialog versus forms for data entry? Have you found them to be free (more stable) from the "personality" that forms can exhibit in a networked environment?

Regards,

Jeff

[Marcel Kollenaar]

Re: Support for 3rdParty Activex/COM in v10?

I'm just trying to track down what doesn't work for Bob. I don't use forms in general. If the ActiveX control works in an Xdialog for Bob then we can go from there. It's easier to figure out what might be wrong if you remove extraneous issues, like whatever else might be on his form.

Peter,

Xdialogs supports the ActiveX job better than forms. An ActiveX can work in a Xdialog environment but does not on a from or works just partially.

[Peter.Wayne]

Re: Support for 3rdParty Activex/COM in v10?

Marcel probably knows more about this than anyone else. However, I think that Alpha Software would fix anything that doesn't work, if it's well documented. At least, that's been my experience -- they are very committed to fixing bugs and improving their product.

As for my preference for Xdialogs -- I believe that you have more control over the end user with Xdialogs. You can prevent a record save or change unless some fairly complicated conditions are met. There's also the inestimable advantage of seeing all the code in one place -- you don't have to wonder whether there's an OnFetch event or an OnSave or OnExit event coded, it's all there in front of you. Xdialogs also enable you to address the problem of childless parent records. Say you have a typical invoice with a header and multiple detail items. Using regular Alpha Five forms, the user has to save the header before the detail items can be entered. If the user abandons data entry after the header is entered, you wind up with a childless invoice header. With an Xdialog, you can enter the parent and all the children as variables, and only when all criteria are met -- say, the sum total of the invoice details must be at least $25 -- only then can the header and the children be saved. Try doing that in forms!