Hello everyone.
I have an Excel based user interface that allows the user to open up a Map with Mappoint 2002 and view the locations of customers that they selected based on account numbers. One of the features of Mappoint is that you can select a group of customers and using the menu "Export to Excel", which creates a new Excel file that has all the data used to populate the map. That's a big problem because I do not want most of the employees to be able to make a ready made mailing list - our customer list is our most valuable asset.
Because Mappoint 2002's object model is not that developed (there is no development environment, but there are more objects than there were in 2000) I cannot capture an "Export to Excel event" and trim the offending fields - and I've given up control of Mappoint already in excel, so I can't monitor for a new workbook and test it's contents from the Excel interface.
Because of this, I think I need to somehow monitor Windows events (so I would probably need API calls) - ideally whenever a new file is either opened or closed. I envision this being accomplished through a VB6 .dll that would be opened along with Mappoint from Excel.
The .dll would monitor Windows and whenever a new file was opened it would see if it was an Excel file, test for the field titles, and if it was the "Export to Excel" file it would remove the offending fields. If Windows found a file being closed, the .dll would check to see if that file was a Mappoint file, if so it would verify that there is no longer an instance of Mappoint, and proceed to shut down the .dll. It would only need to stay up while the "Export to Excel" function from Mappoint can be called, so I need release it once that possibility no longer exists.
This leads to the following questions-
1. Does anyone know how to grab that "Export to Excel" function in Mappoint 2002? That would be a direct solution, but it probably isn't available yet.
2. I'm assuming I need the .dll because Excel doesn't have some type of monitoring event/system ('workbook open' sounds ideal, but I don't believe it can monitor outside of the current workbook - especially when Mappoint initiates the event and Excel doesn't have the focus). I only want to test file openings and closings because I don't want to slow the entire system down if they keep the Mappoint window up all day.
3. From within the .dll, what Windows event / API would I use to have it notified whenever a new file is opened or closed so that I could test it's type (ie, Word, Excel, Mappoint, etc.)
4. If the file open event is an Excel file, can I use OLE automation type code to manipulate it, as in open up an instance of the Excel.Application object, grab the open workbooks collection, test them, manipulate the columns etc.?
Being able to work with Mappoint is one of the most useful features in the application and if I can't figure out how to keep the complete address info from being disclosed, unfortunately I'll have to disable it for most users - which would reduce the value of the app greatly. So I'd be very appreciate of ANY constructive input or insights any of you might have! Thanks.
I have an Excel based user interface that allows the user to open up a Map with Mappoint 2002 and view the locations of customers that they selected based on account numbers. One of the features of Mappoint is that you can select a group of customers and using the menu "Export to Excel", which creates a new Excel file that has all the data used to populate the map. That's a big problem because I do not want most of the employees to be able to make a ready made mailing list - our customer list is our most valuable asset.
Because Mappoint 2002's object model is not that developed (there is no development environment, but there are more objects than there were in 2000) I cannot capture an "Export to Excel event" and trim the offending fields - and I've given up control of Mappoint already in excel, so I can't monitor for a new workbook and test it's contents from the Excel interface.
Because of this, I think I need to somehow monitor Windows events (so I would probably need API calls) - ideally whenever a new file is either opened or closed. I envision this being accomplished through a VB6 .dll that would be opened along with Mappoint from Excel.
The .dll would monitor Windows and whenever a new file was opened it would see if it was an Excel file, test for the field titles, and if it was the "Export to Excel" file it would remove the offending fields. If Windows found a file being closed, the .dll would check to see if that file was a Mappoint file, if so it would verify that there is no longer an instance of Mappoint, and proceed to shut down the .dll. It would only need to stay up while the "Export to Excel" function from Mappoint can be called, so I need release it once that possibility no longer exists.
This leads to the following questions-
1. Does anyone know how to grab that "Export to Excel" function in Mappoint 2002? That would be a direct solution, but it probably isn't available yet.
2. I'm assuming I need the .dll because Excel doesn't have some type of monitoring event/system ('workbook open' sounds ideal, but I don't believe it can monitor outside of the current workbook - especially when Mappoint initiates the event and Excel doesn't have the focus). I only want to test file openings and closings because I don't want to slow the entire system down if they keep the Mappoint window up all day.
3. From within the .dll, what Windows event / API would I use to have it notified whenever a new file is opened or closed so that I could test it's type (ie, Word, Excel, Mappoint, etc.)
4. If the file open event is an Excel file, can I use OLE automation type code to manipulate it, as in open up an instance of the Excel.Application object, grab the open workbooks collection, test them, manipulate the columns etc.?
Being able to work with Mappoint is one of the most useful features in the application and if I can't figure out how to keep the complete address info from being disclosed, unfortunately I'll have to disable it for most users - which would reduce the value of the app greatly. So I'd be very appreciate of ANY constructive input or insights any of you might have! Thanks.
