Ahhh, yeah, that's another level. I believe you're using "regions" to get that done. Again, with the caption, that gets rather complex. I'll let Davey ask for that before I throw myself into that one.
Naa, that's okay; I am thrilled with what you did!!! THANK YOU!! The compiled program is running.
I must say my program is running a lor fast on this new Windows 11 I5- 12600KF processor (~4GHz) than is does on my Windows 7 I7 at 2.7GHz.
This LED issue was one of the reasons I never adopted Windows 10 for the bench. The major one was MSCOMM32.OCX would not work. I guess sometime after Windows 10 was out, it was patched and MSCOMM32 worked again. I just found that out last week or so - LOL. I still hate Windows 10. I really like Windows 11, with the exception of when my cursor ventures near the lower left and that stupid "Current Events/Weather" window pops up. A few curses gets it to close. I will search on how to disable that. Other than that and that VB6 is a real pain in the butt to get installed, I think Windows 11 may become my favorite operating system yet.
I do have a program I did not write that is very old, from the Windows 2000 days, that works fine under Windows 7, but not under 11. I need to use it occasionally. So I will need to keep the Windows 7 system on the bench and updated. I should investigate if I can add a virtual machine to Windows 11 and install Windows 7 on it, or even XP (I have licenses for both). ....but not today.
Now, I wish I could could add User Controls to VBA under Access (Office 2016). So far, I could not figure out how. I think, I only have one program using the LED and it's just for cool looks, and not used as "buttons" like this VB6 program. I just deleted it and remarked out the code. Your LED is so damn nice, I would love to use it in VBA program updates. My most intense test software, the uses VISA code (GPIB) to control and get data from my test equipment while controlling the instrument under test via serial. I did all that programming under Access for the ease of database'ing the data and creating the professions elegant reports. With VB6, I am putting the data out in a .dat file and then using Excel to read the data in and with VBA, creating the reports using a template file and a lot of code to format that report. A major pain in the ass but with good results. Access reports are visually easier to make but still can take a lot of time and the formatting is easier. What's nice with Access a number of my reports end up being self-modifying to an extent, re-arranging themselves based on what they are meant to do.
Anywho, if you do any work in VBA under Office and know how to add this User control, let me know, but it is not urgent or really needed, but would be too cool.
Dave
Last edited by daveyk021; Sep 26th, 2022 at 02:57 PM.
Anywho, if you do any work in VBA under Office and know how to add this User control, let me know, but it is not urgent or really needed, but would be too cool.
Here, I've reconfigured the latest version. I'll outline what I did.
Copy the LedUserControl.ctl to LedUserControlToOcx.ctl
Edit this new LedUserControlToOcx.ctl with Notepad (actually NP++) and changed the line from Attribute VB_Exposed = False to Attribute VB_Exposed = True, and saved.
Started a new project, and changed its project properties to Project Type: ActiveX Control, and Startup Object: (none)
Also named it LedUserControlToOcx, and test-compiled the OCX, also naming it LedUserControlToOcx.ocx
We're not allowed to post executables here (with good reason), but attached is this reconfigured project. All you have to do is compile it: File/Make LedUserControlToOcx.ocx
It'll write out an OCX, an EXP, a LIB, and a OCA file. You can delete all but the OCX, as that's all you need. (But don't delete the CTL or VBP, as that's your source code.)
That OCX will immediately be registered on the machine on which it was compiled. That's part of the compiling process. However, if copied to another computer, it'll need to be re-registered (easiest with RegSvr32, which is on almost all machines). Just get a command prompt, navigate to the folder where you've placed this OCX, and type in: RegSvr32 LedUserControlToOcx.ocx
(If you move this OCX file, you'll need to re-register it.)
After it's registered, it will appear in the Project/Components. You can include it as a component and it will appear in your ToolBox. This is true of both VB6 and the 32-bit VBA. Regarding any 64-bit VBA, you're SOL.
(I actually can't test the 32-bit version of the VBA, as I've only got MS-Office 64-bit these days. But it should work just fine. The 64-bit version doesn't even give you any way to add components at all.)
Enjoy
ADDED: As a last comment, sooo many people have problems getting these OCX files registered. That's why, in the beginning, I advocated for just having your custom UC in with your main project's source code. However, you can't do this with the VBA (not even the 32-bit version). But you can with VB6, which is what you've been doing.
REMOVED ATTACHMENT: Go get the one from post #129, as the one I had here had a bug.
Last edited by Elroy; Sep 26th, 2022 at 05:18 PM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Ok, what am I missing? Eduardo, I pulled the code from your post #118, and that's what's in the above OCX project. I even just did a file-compare, and there were no differences, other than the "Exposed" property.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Ok, what am I missing? Eduardo, I pulled the code from your post #118, and that's what's in the above OCX project. I even just did a file-compare, and there were no differences, other than the "Exposed" property.
Ok, you're right. I just downloaded post #118 and post #123, and they're different.
Sorry, I'll fix it.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Here's the latest version, setup to compile as an OCX (as per discussed in post #123).
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Well I was able to compile it. I got an error unable to access registry, but I copied it to syswow64 and manually registered it.
Under access it shows up as an active x control. When I add it to an existing form, it is huge, so I manually resized it much smaller. Looks good in design mode. With no code, and the caption changed to "What's up Doc?", in form view mode, it's invisible. So in edit mode, I gave it a boarder. The boarder shows up in form view mode, but that's it.
Well I was able to compile it. I got an error unable to access registry, but I copied it to syswow64 and manually registered it.
Under access it shows up as an active x control. When I add it to an existing form, it is huge, so I manually resized it much smaller. Looks good in design mode. With no code, and the caption changed to "What's up Doc?", in form view mode, it's invisible. So in edit mode, I gave it a boarder. The boarder shows up in form view mode, but that's it.
Hmmm, sorry, I'm not able to test (not having a 32-bit version of MS-Office installed anywhere).
In the past years, I've done a lot of work in the VBA. However, I've moved almost all of that work into VB6, and do what I need with Word or Excel via "automation" from VB6. To me, it's just cleaner that way, well, at least for what I'm typically doing. And, VB6 automates 64-bit version of MS-Office programs just fine.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Hmmm, sorry, I'm not able to test (not having a 32-bit version of MS-Office installed anywhere).
In the past years, I've done a lot of work in the VBA. However, I've moved almost all of that work into VB6, and do what I need with Word or Excel via "automation" from VB6. To me, it's just cleaner that way, well, at least for what I'm typically doing. And, VB6 automates 64-bit version of MS-Office programs just fine.
When I got my license for Office 2016, it just came as 32 bit, which is good because it is what I am used to and didn't need hassles and any work arounds. I know I tried Office 2019 and it worked but was a real pain because every database/program needed some large version detection added and large groups of variable re-defines based on what version of office it running under. I had one program running in both Office 2016 (and 2010) and 2019, but it was a lot work and a lot more code. Now, I do not remember if that 2019 was 64 bit, but I don't think that was issue.
Last night, I had to revert this system back to Windows 11 version 21H2, based on Microsoft's recommendation of giving "22H2 several months to mature" - this was a real message from Microsoft in their Windows 11 support forum on Microsoft.com. They know they have issues with it. That is why it shows up as an optional update and not on all Windows 11 machines. I had found out that Keysight's IO Library Suite Could not install or repair, or modify under 22H2. I wasted hours on that. I followed Microsoft's recommendation and then all things VISA/Keysight started working again. Another thing, for me, that stopped working after the update was the Compatibility Trouble-shooter. I had to install VB6 and SP6 again. It was still a pain, but at least time, I knew what to do to get it to install. The system seems solid again this morning.
So that fun set me back a little. I just had to re-register LEDUserToOCX.OCX again. Still not showing in Access 2016/32, BUT I have not tried to make it blink or anything yet, although it is set to blink under parameters. I will play with it a little more when I get a chance. This morning, I am getting an instrument out of here first 8-).
Hmmm, sorry, I'm not able to test (not having a 32-bit version of MS-Office installed anywhere).
In the past years, I've done a lot of work in the VBA. However, I've moved almost all of that work into VB6, and do what I need with Word or Excel via "automation" from VB6. To me, it's just cleaner that way, well, at least for what I'm typically doing. And, VB6 automates 64-bit version of MS-Office programs just fine.
One more problem. When I went to print a report, I was receiving an "Undefined Trim Function" error. The report does not use the control, in fact I deleted it from the form. I tried numerous things. Once I unreferenced LEDUserToOCX.OCX in the IDE, the Trim error went away.
One more problem. When I went to print a report, I was receiving an "Undefined Trim Function" error. The report does not use the control, in fact I deleted it from the form. I tried numerous things. Once I unreferenced LEDUserToOCX.OCX in the IDE, the Trim error went away.
Dave
Are we talking about the VBA or VB6?
In either case, we really need to see the line of code (and some surrounding code) of the error before we could diagnose anything.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
In either case, we really need to see the line of code (and some surrounding code) of the error before we could diagnose anything.
VBA (Access 2016 / 32). As for the line, I don't know, I couldn't get that far. I wasn't using an LEDUserToOCX control anywhere, I just had it referenced in the IDE. As soon as I removed the reference, the database program (specifically report) started running again.
Dave, just as an FYI, I'll be out-of-pocket for a few days (going to Vegas for a few days). Also, maybe someone else will jump in and maybe help with getting it going in the VBA. I'll be back next week, and almost certainly check around VbForums.
Best of Luck,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Hope you trip to LV was fun. This is just a follow up.
Your LEDUserControl has been working perfect in my major VB6 project.
I still have not gotten it to work in VBA, but I am not too worried about that.
Thank you, again !!!
No problem, and yeah Las Vegas was fun. We were just there for 4 days. We're now out camping this weekend, catching some Autumn colors in the Smokey Mountains.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
This LED issue was one of the reasons I never adopted Windows 10 for the bench. The major one was MSCOMM32.OCX would not work. I guess sometime after Windows 10 was out, it was patched and MSCOMM32 worked again.
MSCOMM32.OCX has not had a major problem in a very long time, and was more or less set in stone aside from occasional minor security patches. Even the one I have installed now has a file creation date in 1998.
It has been working in Windows 11, Windows 10 all the way back to its beginning, Windows Vista, and probably Windows 7, Windows 8, and Windows 8.1 though I never tested it there.
I have no doubt that you might have run into issues with it, but I seriously doubt it had anything to do with this OCX itself.
When Windows 10 first came out, we could get nothing that used the serial port to run. Nothing based on MSCOMM32.OCX that is. I never looked back in to using it again. Now that Windows 10 has had updates, it works fine again, and yes, it is working very well in Windows 11. SCOMM32.OCX works too, but I really don't see a need to use it, although on event driven communications, I think its event codes are more accurate. I dunno, I just went back to using MSCOMM32. It would be nice if it allowed 115K. I'll have to check if SCOMM32 does, but I don't think so.
I have been using your LEDUSerControl with success these last few months, but it can be somewhat delicate to changes in the VB6 IDE environment.
By that I mean, that it seems if I add another ActiveX control, i.e., "Microsoft Windows Common Controls 6.0 (SP6)", the LEDs go away and turn in to to just hash marks on the forms.
Any idea how to restore them? It is a LOT of work on some of my forms to re-add them again. Yep, they can be re-added, but the existing LEDS are gone.
I have been using your LEDUSerControl with success these last few months, but it can be somewhat delicate to changes in the VB6 IDE environment.
By that I mean, that it seems if I add another ActiveX control, i.e., "Microsoft Windows Common Controls 6.0 (SP6)", the LEDs go away and turn in to to just hash marks on the forms.
Any idea how to restore them? It is a LOT of work on some of my forms to re-add them again. Yep, they can be re-added, but the existing LEDS are gone.
Thanks much,
Dave
Dave, that's a problem with any/all custom user controls. There are a couple of solutions: 1) compile the LED UC into its own OCX file, and then pull that into your project via components; or 2) while developing just be sure to not open the actual UCs windows in the IDE, not its form designer window nor its code window. If you don't open the UC's windows, you shouldn't have that problem.
ADDED: On that last point, if you need to open the UC's windows, just be sure any form that's using the UC is closed first in the IDE. And, when you're done doing whatever to the UC, be sure to close its windows before opening any form that's using it. Taking that approach usually circumvents any problems like you describe. I suspect that those of us who make regular use of UCs have just learned these habits.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
I had another issue earlier in this project rewrite when the control on the forms (four forms that use the LED), just went BLACK and had to be replaced. I forget what caused that, perhaps importing a new form, I forget.
I am VERY HAPPILY using your control and loving it.
Just to say a bit more ... while in IDE design mode, when you do open a UCs window while also having a form open that's using the UC, the IDE tries to "hatch out" that UC on the form using it. However, that "hatch out" code was never adequately debugged by Microsoft. So, when doing this, your UC (on the form using it) will sometimes just get replaced with a PictureBox. When this happens, it can be quite frustrating.
And again, the solution is to (while in IDE design mode) never simultaneously open the UC and also a form using that UC. For me, once I've adequately debugged one of my custom UCs, I just pull it into a project and then try not to ever touch it again.
I'm glad you're getting good use out of what I did.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Just to say a bit more ... while in IDE design mode, when you do open a UCs window while also having a form open that's using the UC, the IDE tries to "hatch out" that UC on the form using it. However, that "hatch out" code was never adequately debugged by Microsoft. So, when doing this, your UC (on the form using it) will sometimes just get replaced with a PictureBox. When this happens, it can be quite frustrating.
That's for sure!
Here is an example of a program I have been reworking that uses the LED extensively (sorry for the poor resolution) I tried to make it smaller so I could use it here:
That's for sure.
Again, THANK YOU VERY MUCH!
Last edited by daveyk021; Jan 16th, 2023 at 01:07 PM.
ADDED: On that last point, if you need to open the UC's windows, just be sure any form that's using the UC is closed first in the IDE. And, when you're done doing whatever to the UC, be sure to close its windows before opening any form that's using it. Taking that approach usually circumvents any problems like you describe. I suspect that those of us who make regular use of UCs have just learned these habits.
I'm trying to figure this out. The one program I have been developing for month is having this issue (black boxes at run time and blank controls in the IDE) with one form. The other forms that use the LED User Controls is fine.
When I load an older version of the program, that form is fine. So, I copy the form over to the new version. When loading the form, the IDE compains with errors. Then the form is missing the LEDs. I don't understand.
P.S.S. - I know what I did. A week or so ago, I did a File Save-As and renamed the project. That name did not carry through to the forms using the LED control, or at least not all of the forms. I edited the .frm file with Notepad and changed the name of the project references for all the LED references in the form.
Example:
From:
Begin PhasorEvaluationProgram.LED LED1
To:
Begin InstrumentEvaluationProgram.LED LED1
That fixed the form to where the LEDS came back again. Weird, the main form and one other form still worked fine....
One thing you could try is to run your VB6 and VBA programs in compatibility mode for Windows 10. Right-click on the program's shortcut, select Properties, go to the Compatibility tab, and check the box for "Run this program in compatibility mode for" and select Windows 10 from the dropdown.
Reply With Quote
Originally Posted by Elroy
