Inconsisten API in bitmap download from SW 2

[TheTick]

I downloaded and attempted to run a VB macro to extract and display preview bitmaps from SW files. It does not work. I found many inconsistencies in the code.

Is anyone familiar with this sample? Downloaded from

http://www.solidworks.com/pages/services/APIDownloads.html

under the link titled "VBA Project to display bitmap previews". The downloaded file is SldWorks_GetPreviewBitmap.zip

I found some API calls that are not in the API documentation, or on the SolidWorksDeveloper.com site (wasted $25). Also a few basic syntax errors lead me to believe the code never ran.

1.) vConfName = swApp.GetConfigurationNames(txtFileName.Text)
I find no application object methods for this. It causes an error.

2.) Set swPreview = swApp.GetPreviewBitmap(txtFileName.Text, ddlConfig.Text)
ditto

3.) frmPreview.Show True
should read just frmPreview.Show

4.) uses Common Dialog object to open files. Works fine on computers that have VB installed, but not w/ VBA.

Any comments?

Good and evil: wrap them up and disguise it as people.

 

[SBaugh]

Since you downloaded this file...could it be because it is an older program using different callouts than the SW03 uses? (Just a thought)

Sorry you wasted your cash at Solidworks Developer. Email him and ask them, if you haven't already.

Regards,

Scott Baugh, CSWP
3DVision Technologies

http://www.3dvisiontech.com

http://www.scottjbaugh.com

faq731-376
When in doubt, always check the help

 

[TheTick]

I'll stick w/ SW developer for the year in case it comes in handy. I was hoping for a more depth of content, though.

I run SW2003 at work and SW 2001+ at home. The calls are not mentioned in either of those. Also, the website says file was last updated january 2003. Also, obsoleted API should still run, it's just not supported (so they say). Still, other errors make the code questionable. Did they even test run any of this?

 

[rocheey]

well, I havent actually played with this particular code, because the box Im on now doesnt have the common dialog control installed, as well. But heres what I could pick out:

1.) vConfName = swApp.GetConfigurationNames(txtFileName.Text)

>>The GetConfigurationNames call has been avail since 2001 plus, but it references the MODEL object (a model already open)instead of the app object, and does not not ask for a param to be passed.

2) Set swPreview = swApp.GetPreviewBitmap(txtFileName.Text, ddlConfig.Text)

>>At least up until SW03/sp0 (whats on this current box) there is no GetPreviewBitmap call available, not even an undocumented call.

3) frmPreview.Show True
>>You can use "0" or "1" as modal params in newer VBA installs, but Trues resolve to -1, an error.


But what really strikes me here are the references to what appears to be unopened sw documents. This could mean a few things:

1) These calls are all available in some newer Service pack of SW, and these calls are now these 'uber-calls' that do everything with one line of code <--- doubtful, especially since the referenced link says it hasnt been updated for 8 months or so

2) These calls reference an external .tlb, which I think may be more the case, since VB/VBA alone cant access the structured storage directly.

There is no missing reference to a .tlb in the Object browser tho.

 

[TheTick]

rocheey:

I have a form for selecting SW files. Not as slick as Common Dialog, but it works. Email me at the address in my profile if you're interested.

I'm kind of surprised to hear you're in this position. Didn't you supply me with some Common Dialog API calls and subroutines info a while back?

Good and evil: wrap them up and disguise it as people.

 

[rocheey]

haa haa, yes. I do, and yes, I did. But the problem here was to download some obviously buggy code, then start replacing some of the (Common Dialog) references with my own, just to find the NEXT buggy call you are talking about. Thats more of a Friday afternoon-thingm than a Monday Morning thing <grin>

 

[dsi]

I just downloaded, unzipped and ran the macro and it worked just fine without a single tweak. Looking that the References, this is what it requires:

VBA
SW Ext Type Library: swvba.tlb
OLE Automation: STDOLE2.tlb
SW 2003 Type Library: sldworks.tlb
MS Forms 2.0: FM20.dll
MS Comm DLG: Comdlg32.ocx

You should be able to get these common files somewhere on the net. If not, drop me a line.

The call to SldWorks::GetConfigurationNames is valid and listed under:
SolidWorks Objects
- Application Objects
- SldWorks
- Methods
- GetConfigurationNames
The passed item is the path and filename for the part. This, as well as GetPreviewBitmap are available on 2003 SP1, RevisionNumber 11.1.

DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

 

[rocheey]

hmm, this is the second time I got bitten by SW03, SP(+0) code. The APPLICATION call for getConfigurationNames is not available in sw03, sp0, nor is the getPreviewBitmap call.

Guess it's finally time to force the IT guy to install the service packs (yes, we've got the plan, and the cd's are just laying around) or maybe its time to upgrade our IT guy :/

 

[dsi]

I never realized that they added new functionality at the SP level. I assumed that they just concentrated on working out the bugs, figuring they had plenty to do.

DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

 

[TheTick]

I have SP 3.1. The call SldWorks::GetConfigurationNames is not available. I opened up the SldWorks library in the VB editor Object Browser and it's not there, either.

Good and evil: wrap them up and disguise it as people.

 

[dsi]

I am using SP4, although that should not matter since they indicate its availability since SP1. Are you including the correct type library in your references? If you have multiple instances of SW, you may not be using the latest file. I see GetConfigurationNames in the Object Browser as well as the help files. Maybe it was available in 4.0 and they messed up the availability in the Help file. The 4 and 1 are aweful close to each other on the keypad?!? I looked at the properties of sldworks.exe and noticed the file version of &quot;11, 1, 0, 0400&quot;. Maybe that's the Revision 11.1 they were talking about.

DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

 

[TheTick]

Some resolution to the issue...

We have a new guy who got a new computer and a new release of SW2003 that came with SP3.0 on the disk. His API help and libraries had these functions. I copied his over and now I have them. Why was this not updated when I ran the SP?

As far as the Common Dialog, still no go. I've noticed something about Common Dialog: I can access it directly in a SW macro if I am running on a machine that has stand-alone VB. Otherwise, I must resort to using API.

Thanks all, especially dsi, for you help.

Go Packers!

Good and evil: wrap them up and disguise it as people.

 

[dsi]

TheTick:

If you have access to a machine that has the common dialog control, you can add it to your VBA projects. Just copy the file (comdlg32.ocx) to your Windows (or WINNT)\System32 folder. Then, from the command prompt, register the ocx file using the following command:

regsvr32 c:\winnt\system32\comdlg32.ocx

Then, if it doesn't appear in your References list, you should be able to browse to it to add it to your project.

DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

 

[dsi]

TheTick:
Did you try the above method for adding the common dialog control to your system? Let me know how it works.

DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

 

[TheTick]

dsi:
Everything was in place per your recommendations. I did get some info from a friend. He said that it is a licensing issue. The Common Dialog object is not licensed for VBA and should not work. Hmm... I used MS API to work around.

Bigger problem:
The sldworks.tlb type library does not seem to update with service packs. It doesn't seem to be available on the solidworks.com website. Also, the &quot;latest&quot; help file is the same outdated one I already have. I'm already talking to my VAR about this one. I think this is pretty serious.

I did get the latest sldworks.tlb off of a coworkers computer, who has a later release of SW2003 which is SP3.0 right off the CD.

Good and evil: wrap them up and disguise it as people.

 

[dsi]

I guess by &quot;common&quot;, they don't mean commonly available to everyone. >!?)(&#%

The update issue is strange though. We installed 2003 SP0 from the disk. Since then, we have updated with service packs. We did, however, skip SP3. Here are the updates we applied:
0.0 - 1.0
1.0 - 2.0
2.0 - 2.1
2.1 - 4.0
Needless to say, my system updated properly. I wonder if they left off the tlb and hlp in the 3.0-4.0 upgrade.


DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

 

[rocheey]

Ive found all I usually have to (remember to) do is click the &quot;tools&quot;, &quot;references&quot;, and then browse to the *same damn file in the same damn path* already listed as the previous .tlb, and watch the listed ver 'upgrade'...

 

[dsi]

TheTick:

I just found how you can use the ComDlg through the API using the dll versus the ocx. Not sure if this is what your already doing, but here it is anyway.

Option Explicit

Private Declare Function GetOpenFileName Lib "comdlg32.dll" Alias "GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As Long

Private Type OPENFILENAME
  lStructSize As Long 
  hwndOwner As Long 
  hInstance As Long
  lpstrFilter As String
  lpstrCustomFilter As String
  nMaxCustFilter As Long
  nFilterIndex As Long
  lpstrFile As String
  nMaxFile As Long
  lpstrFileTitle As String
  nMaxFileTitle As Long
  lpstrInitialDir As String
  lpstrTitle As String
  flags As Long
  nFileOffset As Integer
  nFileExtension As Integer
  lpstrDefExt As String
  lCustData As Long
  lpfnHook As Long
  lpTemplateName As String
End Type

Private Sub Command1_Click()
  Dim OpenFile As OPENFILENAME
  Dim lReturn As Long
  Dim sFilter As String
  OpenFile.lStructSize = Len(OpenFile)
  OpenFile.hwndOwner = Form1.hWnd
  OpenFile.hInstance = App.hInstance
  sFilter = "Batch Files (*.bat)" & Chr(0) & "*.BAT" & Chr(0)
  OpenFile.lpstrFilter = sFilter
  OpenFile.nFilterIndex = 1
  OpenFile.lpstrFile = String(257, 0)
  OpenFile.nMaxFile = Len(OpenFile.lpstrFile) - 1
  OpenFile.lpstrFileTitle = OpenFile.lpstrFile
  OpenFile.nMaxFileTitle = OpenFile.nMaxFile
  OpenFile.lpstrInitialDir = "C:\"
  OpenFile.lpstrTitle = "Use the Comdlg API not the OCX"
  OpenFile.flags = 0
  lReturn = GetOpenFileName(OpenFile)
  If lReturn = 0 Then
    MsgBox "The User pressed the Cancel Button"
  Else
    MsgBox "The user Chose " & Trim(OpenFile.lpstrFile)
  End If
End Sub
[code]

DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

 

[TheTick]

Thanks, dsi[/i]. That's what I've been doing. I got that already from a previous post specifically about the subject. That started me down the trail of exploring Windows API calls (scary big world!).

To all our faithful listeners out there in SW Land:
API function calls re a pretty handy way to augment SW macros with items that don't always work directly. I recommend

http://www.allapi.net

All this machinery making modern music can still be open-hearted.