Does anyone want a specialist ActiveX control made that will make their lives easier?
I'm currently looking into all aspects of ActiveX.
Printable View
Does anyone want a specialist ActiveX control made that will make their lives easier?
I'm currently looking into all aspects of ActiveX.
How about an advanced version of a RichTextBox? Something that supports different types of Underlining (Double, dashed, dotted etc.), highlighting, Line Numbering and mnay other different functions.
Kind of like the Box that is in the Advanced Word Processors such as MSWord and WordPerfect.
how 'bout a data bound grid (like the DBGrid) that allows for check boxes, combo boxes maybe even the datetimepicker etc... if you ever get this one going let me know!
I`ve been complaining alot about this... I have seen many people complaining about it too, maybe you can do something.
Ever played with maskedit control or datepicker control from VB? Ever realised how a date-formatted textbox from Access is so much better?
I would appreciate a control for VB that acts exactly as a textbox (with a date format) in access (97, 2000). You have a mask, an auto checkup if the date entered is valid, some other stuff AND: you can let the goddamn control empty! (unlike a date picker) If you have a customer form playing with a database, you can't use a datepicker because it can't be empty... Which date would you choose as a DOB default date? Now - 20 years?...
I'm sure you see what I mean...
Ciao.
Why can't you set the checkbox property of the dtpicker to true, so if you don't want to select a date, just uncheck it (or, programmatically, set it's .value = vbNullString)?
ActiveX with methods replacing the majority of commonly used API calls. I hate those things.
Wow, I forgot all about this thread.
Jethro, I think I'll to a variation on your idea, but instead of an activex component, i'll just do a simple module file that encapsulates all the constants and functions, replacing them with more desctiptive argument names!
I think using a DLL in this way will lose all of the speed gained by using API functions in the first place. A module will get around this.
What do ya think?
;) :confused: ;)
but all u would hafta do is give each function an alias! whats the big deal? y not work on something more useful like that richtextbox idea?
:oSpetnik,
Well, Using aliases would be only a part of it. You could write it so that you can have default arguments where the original does not allow, add more arguments for coordinates (for example) and then have your shell version convert it to a POINT datatype before sending it to a function like PolyLine() or whatever.
There is a lot that can be done by simply writing a shell to hide the original declarations, and thus making debugging easier.
Anyway, there are plenty of richtext clones out there, some are better than the original! At least I can write a library shell that is easily adaptable to each person's needs.
I just spent a week or so coding a scroll bar from scratch. It's not an ActiveX control, but it could easily become one. This version looks similar to a normal scroll bar, but includes 2 additional buttons. I need it for a graphics program that I was writing, and wanted to have Page Back, Item Back, Item Forward, Page Forward button sets.
The Buttons Were Arranged Something Like This:
[<<] [<] [-----------[]--------------[>] [>>]
In addition to just adding 2 more buttons, I expanded on the events and properties.
- There were 2 Value change events. One would fire if you changed the position of the slide bar, and the other would fire if you changed the Value property through code. (The original slide bar could at times create feedback loops in code, where a slide bar change caused the Change event to fire, then your code might have to run some recalculations of the values that could cause the Change event to fire again.)
The Min, Max, and Value properties used Double type variables versus Integers, to give you greater flexibility.
The Arrows on the buttons changed color when the mouse hovered over them.
All 4 Buttons raised there own events.
The Large/Small change concept was expanded to allow you to specify a change value for each of the 4 buttons, and for clicking the slide button's track.
The Large/Small Value changes could be turned off, so that only sliding the slide bar actually changed the Value property. (or code)
All shadows and colors could be dictated.
This scheme has worked really well, and could be applied to all sorts of applications. It also got my application past a bug that is in the VB slide control - in which the buttons would not pop up or would multi-fire if the change event caused large amounts of graphics to update. This meant that sometimes when you click one of the scrollbar buttons, the program would go nuts with hundreds of Value Change Events !!!!
Let me know what you think.