|
AnyWay Thanks For Ur Kindly info..
Thank you
in Msn Messenger : renji12renji@hotmail.com
|
|
|
|
|
Hello All,
In my project, I am using IStorage::CreateStream(). What I am doing is creating storage, and adding a file into the stream. For that I am using CreateStream, but the problem is, if the file name is large my program is crashing. I read MSDN, that CreateStream can't handle large filename (more than 31 characters.) Its giving me an error invalid pwcsName.Is there anyway to handle this problem???
Or is there any alternative which can solve this problem. Please, help.
Thanks,
|
|
|
|
|
I answered this in the C++ section: here
"The greatest danger to humanity is humanity without an open mind."
- Ian Mariano
http://www.ian-space.com/
|
|
|
|
|
Note :
Storage and stream names cannot contain the characters /,\,:, or !. If the first character has an ASCII value of the less than 32, the element is marked as managed by some agent other than the owner.;P
|
|
|
|
|
Hi All,
I was trying to write component in which I perform database access only once and return the IRowset* to client. In subsequent client requests, CCommand is built using client given IRowset* without making d/b connection again.
Here is how it goes.
I built CCommand<Accessor<CMyAccessor> > and Opened it using a CSession-obj and extracted IRowset* and other public members from CCommand. I closed CDataSource,CSession not CCommand.
Later I want to build CCommand<> again by assigning IRowset* etc to it.
The problem is I am able to iterate CCommand but CMyAccessor-members the current record holds are garbage values.
Does anyone know the missing steps? Please let me know!
Here goes the code.. (VC++/ATL/SQL Server OLEDB Driver)
//--------------------------------------------------------
// CCommand members to be used in 2nd section
ICommand *pCommand=0;
IRowset *pRowset=0;
_ATL_ACCESSOR_INFO AccInfo={0};
//---------------------------------------------------
//1st Section opens CCommand using session
//---------------------------------------------------
CDataSource connection;
CSession session;
CCommand<CAccessor<CMyAccessor> > cmd;
// establish connection and session
// command opened successfully
cmd.Open(session,"select * from tab1");
//Extract members
pCommand = cmd.m_spCommand.Detach();
pRowset = cmd.m_spRowset.Detach();
AccInfo.bAutoAccessor =
cmdCalDefault.m_pAccessorInfo->bAutoAccessor;
AccInfo.hAccessor = cmdCalDefault.m_pAccessorInfo->
hAccessor;
cmd.Close(); // do nothing as such
session.Close();
connection.Close();
//---------------------------------------------------
//2nd Section builds CCommand using IRowset*
//---------------------------------------------------
CCommand<CAccessor<CMyAccessor> > cmd2;
//Assign to CCommand
cmd2.m_spCommand = pCommand;
cmd2.m_spRowset = pRowset;
cmd2.m_pAccessorInfo = &AccInfo;
cmd2.m_nAccessors = 1;
// Iteration of cmd2 gives garbage values
//--------------------------------------------------------
Regards
Rohit Arora
VC++ Team Member
rohita@dsrsolutions.com
|
|
|
|
|
I was developing a COM. It's a DLL. Also I include MFC support.
I've choosen Apartment threading model. Dual Interface support. And no Aggregation support.
The business logic is written with the help of CInternetSession class. Actually I was trying to get the source of a URL.
Now after implement the business logic. I build the COM DLL.
After building the the COM DLL successfully. I used the COM with VB. The VB program has a GUI.
I don't know why it freezes the GUI when it start retreiving the source of the URL. As the COM Framework covers the threading detail itself.
Any body has the answer
Dammy More
|
|
|
|
|
Hi, I want to create an application which will have three "services" (not necessarily NT services). I need fast and frequent IPC calls, and think that COM is probably the way forward for this.
One of these services will need to communicate with the two others, and those two others will need to know about the first.
When defining the interfaces for these services, should I create a single IDL that defines all three? Surely this will reduce include complexity? Am I correct in thinking that the best way to do so is to derive from IUnknown - or should I be aiming at IDispatch?
Having defined that IDL, is the best way to attempt to compile that into a .tlb and import it in the other projects?
I'm relatively new to COM so please excuse my lack of knowledge...
Thanks in advance for any advice or suggestions you can give me. I am trying to work my way through Essential COM while programming with ATL7 - something which doesn't exactly ease the process of getting into COM 
--
Simon Steele
Programmers Notepad - http://www.pnotepad.org/
|
|
|
|
|
Simon Steele wrote:
Hi, I want to create an application which will have three "services" (not necessarily NT services). I need fast and frequent IPC calls, and think that COM is probably the way forward for this.
One of these services will need to communicate with the two others, and those two others will need to know about the first.
When defining the interfaces for these services, should I create a single IDL that defines all three? Surely this will reduce include complexity? Am I correct in thinking that the best way to do so is to derive from IUnknown - or should I be aiming at IDispatch?
Having defined that IDL, is the best way to attempt to compile that into a .tlb and import it in the other projects?
I would go for a single IDL and .TLB because there are inter-dependencies between the interfaces, as it seems it is your first ATL project.
About the IDispatch, using ATL, I would definitively recommend you to declare your interfaces as dual, so they are exposed both as custom interfaces (derive directly from IUnknown) and have the IDispatch implemented too. Take care and only use automation types, this makes things easier for your clients. You'll never know when your COM object will be used from scripting clients or beginner VB programmers, and God knows why, they find IDispatch easier...
The ATL COM wizard have an option that generates the dual interfaces declaration and the IDispatch implementation for you, so, normally this is a no-brainer.
Q261186 - Computer Randomly Plays Classical Music
|
|
|
|
|
Daniel Turini wrote:
About the IDispatch, using ATL, I would definitively recommend you to declare your interfaces as dual
Thanks, I'll try it. I'm only working on experimental projects at the moment so it doesn't matter too much if I get it wrong and need to start again. But you know how these experimental projects suddenly become sold products!
Some of this stuff is really clever, I am being repeatedly amazed 
Do I need to separate the interfaces from the classes in this separate IDL file? I might want to create multiple objects that expose the same interface and am not entirely clear on how to do this sanely!
Thanks again for your help,
--
Simon Steele
Programmers Notepad - http://www.pnotepad.org/
|
|
|
|
|
Simon Steele wrote:
One of these services will need to communicate with the two others, and those two others will need to know about the first.
If each service is a COM object, then you'll have 3 idl files. Reusing idl file from one COM service into another is not an option since GUID, LIBID, CLSID, IID would be the same. It's sad MIDL is really limited when it comes to sharing idl interfaces, although you have the import and importlib statements.
Simon Steele wrote:
Thanks in advance for any advice or suggestions you can give me. I am trying to work my way through Essential COM while programming with ATL7 - something which doesn't exactly ease the process of getting into COM
I recommend to stay low-level. You'll get code skeletons from the book "Inside COM" MS PRESS, which I recommend. And this source code doesn't obfuscate at all what is done, unlike ATL.
ATL is fast for coming up with COM servers, but the learning curve is huge (in fact, you won't get your own ATL COM server running without actually hacking what ATL does, which requires huge time when you don't know it).
That said, I can't come up at the moment with a decent listing on CodeProject who would have just that, but beware of code filled with macros...
How low can you go ?
(MS rant)
|
|
|
|
|
If I split the interface and class definitions, then surely I can have a single .IDL file for the three which defines the interfaces? Then each can implement classes and libraries which contain implementations of those interfaces? As I said I'm new to this, but it does seem to be hinted at in the book I'm reading.
__Stephane Rodriguez__ wrote:
You'll get code skeletons from the book "Inside COM" MS PRESS,
I'm trying to make my way through Essential COM by Don Box which is great, but the shear amount of code to do this stuff without ATL seems incredible!
--
Simon Steele
Programmers Notepad - http://www.pnotepad.org/
|
|
|
|
|
Simon Steele wrote:
If I split the interface and class definitions, then surely I can have a single .IDL file for the three which defines the interfaces? Then each can implement classes and libraries which contain implementations of those interfaces? As I said I'm new to this, but it does seem to be hinted at in the book I'm reading.
Yes, at least in theory, and it will even compile. But I am not sure it will run. I had this problem, and the .tlb was not including the idl stuff I was including in the main idl. So it was ok for compilation time. But only for compilation time.
Simon Steele wrote:
the shear amount of code to do this stuff without ATL seems incredible!
That's a fake. May be I publish COM skeletons sometimes in the future so you figure out it's damn light, easy, DEBUGGABLE (unlike ATL macros), neat and reusable. (as you can see, I am not a big fan of ATL  ).
How low can you go ?
(MS rant)
|
|
|
|
|
__Stephane Rodriguez__ wrote:
That's a fake. May be I publish COM skeletons sometimes in the future so you figure out it's damn light, easy, DEBUGGABLE (unlike ATL macros), neat and reusable. (as you can see, I am not a big fan of ATL ).
Agree entirely. Please do publish your code 
Len Holgate
www.jetbyte.com
The right code, right now.
|
|
|
|
|
I have an application which needs to find any available COM objects in a given area/category. For example, my app could start up and look for what COM objects it has available. This would allow me to register new COM objects and know my app will pick them up next time it starts up.
If I want my app to find the COM objects I could just look them up in the registry but that would only work if my app already knew the names of their interfaces or their GUIDs. I need my app to determine the name/GUID of the COM objects it handles at run-time.
In other words, it would be nice to be able to group my COM objects hierarchically so that I can find all the COM objects I'm interested in easily. My app just specifies the parent "directory" in the registry and then looks in that directory for all the COM objects it's interested in.
Can anyone suggest a way of doing this?
Thanks.
"The folly of man is that he dreams of what he can never achieve rather than dream of what he can."
|
|
|
|
|
|
Thanks for the link, I had already come across the idea of categories but I'd heard there were some problems with older Windows OS versions such as 95 and 98. Nevertheless, I've read through that link and written some code, and it certainly works OK so far. I can't find the article describing the problems with older OSes now either but it's not really that important while my code is working just fine
"The folly of man is that he dreams of what he can never achieve rather than dream of what he can."
|
|
|
|
|
Hi ,
I am trying to access a property of an activex control and in
code statement
InvokeHelper() it pops up a message box telling its a runtime property.
how to avoid this??
waiting for ur replies eagerly.
pradeep
|
|
|
|
|
I am making com using ATL recently.Now I encounter a insidious question.That is I want pass a struct to com.
How can I solve this question?
|
|
|
|
|
define your struct in idl file
I am seeking...
For what?
Why did you ask me for what? I don't know!
|
|
|
|
|
hi all,
My problem is that I created a ATL COM named "Controller". The com has one method, "CheckOnline" as below:
//IDL
interface IController : IDispatch
{
[id(1), helpstring("method CheckOnline")] HRESULT CheckOnline([out] BSTR* mdln, [out] BSTR* softrev);
};
//C++ implementation
STDMETHODIMP CController::CheckOnline(BSTR* mdln, BSTR* softrev)
{
// TODO: Add your implementation code here
*mdln = ::SysAllocString(L"testing");
*softrev = ::SysAllocString(L"1.2");
return S_OK;
}
and then I compliled and deploy the com sucessfully. Now I create a VB client as below:
Dim eq As New EQCONTROLLERLib.Controller
'Set EQController = CreateObject("EQPController")
Dim param1, param2 As String
Call eq.CheckOnline(param1, param2)
txtParam1.Text = param1
txtParam2.Text = param2
when compling VB Client, I get the error: "Byref Argument Type Mismactch"
oh, Why's that ! Is my way is correct??? Is there another way to get out parameter as BSTR string in VB client???
thanks for your help !
Huu Pham
|
|
|
|
|
[OK everyone, duck! This message contains VB references (aka mild bad language)]
Try
Dim param1 As String, param2 As String
Unlike C/C++, VB needs the type to be associated with each variable in a declaration list.
Steve S
VB? Me? Are you crazy?
|
|
|
|
|
I am building an Ad Hoc tool for work. Using a DLL to access the SQL Server database via ADO Smart Pointers (_RecordsetPtr, _ConnectionPtr).
Anyway after I generate the SQL string the end user will create it gets truncated when converted to the BSTR datatype (which is necessary to pass out of the DLL via IDL).
It appears to truncate at 511 chars (so I assume BSTR maxes at 512 with a NULL terminating character).
What I need to know is if there is a way around this limitation. Is there a wrapper or function that expands the length of the BSTR to be passed?
Or is there away to send it in pieces and have SQL Server concatenate it together when it receives it?
I know that Query Analyzer, Cold Fusion and other tools pass incredibly long strings to SQL Server so it's got to be possible!
Does anyone know the trick? Please let me know!
Adam Murray
Contract Programmer
Microsoft Certified Professional
|
|
|
|
|
nativespirits wrote:
I am building an Ad Hoc tool for work. Using a DLL to access the SQL Server database via ADO Smart Pointers (_RecordsetPtr, _ConnectionPtr).
Anyway after I generate the SQL string the end user will create it gets truncated when converted to the BSTR datatype (which is necessary to pass out of the DLL via IDL).
It appears to truncate at 511 chars (so I assume BSTR maxes at 512 with a NULL terminating character).
I don't know how long they can be, but I guess they can be as long as available system memory. This should be enough for your query
Are you using wsprintf for building the query? wsprintf has a limit of 1024 bytes, wich should be 512 chars on a UNICODE build. If so, use _snwprintf...
Q261186 - Computer Randomly Plays Classical Music
|
|
|
|
|
It's probably a limitation of ADO. There's one way to get around that problem but I don't think you want to hear it 
Todd Smith
|
|
|
|
|
BSTRs have no limitation other than physical memory and address space size (2GB). Something else is truncating your strings.
--Mike--
"I'd rather you just give me a fish today, because even if you teach me how to fish, I won't do it. I'm lazy." -- Nish
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
