|
I am facing the following peculiar problem:
1. Create a dialog based applications.
2. Show a modeless dialog box on click on a button
3. Show an AfxMessageBox on click of another button on base dialog.
4. Close the modeless dialog box.
5. Now you can click on any button on the base dialog to create a second afxmessagebox,while the first one is still displayed!!!!
How can you prevent this?
|
|
|
|
|
You can keep all the modeless dialogs in a CWnd* p[max_no_modlesses] and:
void CDlg::OnButtonAfxMessageBox()
{
for (int i=0; i<no_modelesses; i++)
p[i]->EnableWindow(FALSE);
AfxMessageBox("AAAAAAAAA");
for (i=0; i<no_modelesses; i++)
p[i]->EnableWindow(TRUE);
}I assume you don't want to manipulate any modeless while AfxMessageBox is "running".
rechi
|
|
|
|
|
How can I create a MSI file for my VC .NET project ? I created a very simple COM, and want to distribute to clients. What the MSI needed is just put my DLL in a place, and install VC7 related stuff to run my DLL together with registration it correctly.
Can I still use the Free Windows Installation tool exists in VS6's platform SDK ?
I don't want to buy InstallShield as it's quite expensive. More expensive than VS.NET.
|
|
|
|
|
|
Oh...thanks, it's creating another project, not a seperate tool.
|
|
|
|
|
However, I still got problem. My COM DLL is dependent on another traditional DLL developed in VC++ .NET. In order to work properly, any merge_modules I should add too ? Should I add VC_atl, VC_stl, VC_CRT, VC_MFC ? It is by default added dotnetfxredist_x86_enu.msn, so i don't have to bother about the .Net framework installation, right ?
|
|
|
|
|
|
My project's view class is not derived from CScrollView and the view area is a Modeless dialog, which contains a RichEditCtrl.
Can anybody give any help on how to add scrollbars to scroll RichEditCtrl's contents in the Dialog Window???
(Creating the RichEditCtrl using WS_VSCROLL and WS_HSCROLL doesn't help as I need the scroll bars to be in the Dialog window).
I appreciate any help!!
|
|
|
|
|
I want to improve my application with two techniques:
1. Plugins. I think it's better to export application class (object). Should I use COM or something else?
2. Automation. So my app could be called/controlled by another. Should I get into OLE automation/IDispatch stuff?
It's new deal to me so I really need advices from more experienced programmers.
Thanks in advance
|
|
|
|
|
As for your first question:
You shouldn't, but you may.
You can use COM, but remember that the only way
to identify a COM class is its CLSID (GUID).
Therefore, your main program (client) would have to know
CLSID's of all plugins existent on the machine.
Plugins should have to register (as any COM servers),
and should make the main program know their CLSID's.
Plugin DLL's can locate anywhere.
So, the usual approach to plugin search
in a fixed directory (e.g., as in FAR)
is not applicable in this case.
Whether to use COM or not, depends much on the way
the plugins should be written.
If you want any third party to be able to write a plug-in
using any development tool, you'd better use COM.
If you plan to write them yourself,
you may use just DLL's with a fixed set of entry points
(imho, COM development is not that simple,
especially for the beginner - mainly, bcause of the
huge set of specific terms involved
in the description of its techniques).
As for your second question:
Yes, you should.
It seems to be the only way.
|
|
|
|
|
Well, I see that the usage of every plugin like a COM-server is too expensive and tricky.
And what about mixed technique?
1. Fixed set of entry points (just to initialize plugin and to obtain menu entries and corresponding functions addresses). Using COM-friendly and language-independent syntax, of course.
2. Host app starts one of the plugin's function. Handler is about to get (or it may be done on initialization phase) "Appclass" object with known single COM-interface of Appclass. (is it Automation itself?  )
So, the idea is to make plugin work like hostapp COM-client.
What do you think?
|
|
|
|
|
If you rely on the set of DLL entry points,
you also imply certain call agreement for
these exported functions.
What are the advantages of using mixed approach ?
I can see none.
If you decided to use COM, you'd better export from the plugin
nothing than one COM class (maybe, with a single inteface).
You can initialize plugin, obtain menu entries, etc.,
just via that interface.
The point is, if you avoid using COM,
you simplify the task for yourself.
Buyt if you do use COM, then better
do everything via it.
The mixed technique will be both complex
and less portable.
If your plugin is a standalone DLL,
serving as an extension to your specific application,
I suppose it's not yet automation.
Automation, afaik, refers to the usage of the objects
implemented in one program from another one,
or control of one application over another.
E.g., from your app you start Word, open some document,
make there text replacement, close it, etc.
|
|
|
|
|
As for your first question:
You shouldn't, but you may.
You can use COM, but remember that the only way
to identify a COM class is its CLSID (GUID).
Therefore, your main program (client) would have to know
CLSID's of all plugins existent on the machine.
Plugins should have to register (as any COM servers),
and should make the main program know their CLSID's.
Plugin DLL's can locate anywhere.
So, the usual approach to plugin search
in a fixed directory (e.g., as in FAR)
is not applicable in this case.
Whether to use COM or not, depends much on the way
the plugins should be written.
If you want any third party to be able to write a plug-in
using any development tool, you'd better use COM.
If you plan to write them yourself,
you may use just DLL's with a fixed set of entry points
(imho, COM development is not that simple,
especially for the beginner - mainly, bcause of the
huge set of specific terms involved
in the description of its techniques).
As for your second question:
Yes, you should.
It seems to be the only way.
|
|
|
|
|
I Read the article http://www.codeproject.com/useritems/asyncwininet.asp;
and write the code like 'asyncdemo' which from msdn:
http://msdn.microsoft.com/downloads/samples/internet/default.asp?url=/downloads/samples/internet/networking/asyncdemo/default.asp
but I have a question 
when I call InternetQueryDataAvailable() ,it return ERROR_IO_PENDING
then I will recieve a callback status :INTERNET_STATUS_REQUEST_COMPLETE
and the LPINTERNET_ASYNC_RESULT (lpvStatusInformation)->dwError!=0,
the download incorrect. 
what's the matter??? 
the 'asyncdemo' alse download file incorrect
who have the source code of asynchronous download
thanks very much
|
|
|
|
|
Before asking Chris to add this one as a 'bug' in MSDN, maybe someone can shed a light on the following.
In MSDN for CRect::Width() I read:
Calculates the width of CRect by subtracting the left value from the right value.
The width can be negative
I read something analog for CRect::Height():
Calculates the height of CRect by subtracting the top value from the bottom value. The resulting value can be negative.
And in a note for both:
The rectangle must be normalized or this function may fail. You can call NormalizeRect to normalize the rectangle before calling this function.
While I read for CRect::NormalizeRect():
Normalizes CRect so that both the height and width are positive.
Then is my question: "How can the result of CRect::Width() or CRect::Height() be negative if you must normalize it first?
|
|
|
|
|
Use the source, Luke ... 
From afxwin1.inl (VC6):
_AFXWIN_INLINE int CRect::Width() const
{ return right - left; }
_AFXWIN_INLINE int CRect::Height() const
{ return bottom - top; }
These function can't fail, unless MSDN means returning negative value by failure.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
i want drag a URL in IWebBrowser2. and release mouse in the same window. and open the URL. so i use IWebBrowser2::put_RegiseterAsDropTarget. but no effect. why.
i'm sorry for my eng is too bad. i'll try my best to clarity.
|
|
|
|
|
Hi,
I am facing a problem.
Following is the description:
I have a COM server(EXE).
It has a method, "ServerMethodAAA". The "ServerMethodAAA" method, calls a Dll function, "DllFuncDlg()". "DllFuncDlg()" function invokes a dialog box.
I have a client app for my COM Server, which loads COM Server in hidden mode.
Problem:
When client calls method, "ServerMethodAAA", the dialog is displayed in hidden mode. That is, behind client application. I want that dialog should appear in fore ground window.
Please suggest me.
Regards.
|
|
|
|
|
Is the dialog a modal dialog (stops program execution until you close the dialog). If so the only thing that you will be able to do is modify the code inside the DllFuncDlg() function to make sure that the dialog is brought to the foreground with a call to SetForegroundWindow().
Otherwise if the ServerMethodAAA function returns and the dialog is a modeless dialog, then you can call SetForegroundWindow right after your call to ServerMethodAAA.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Hi there,
Can u pls tell me the events to be trapped to know when a CDialogBar is 1]Docking and 2]Floating?
I need to resize my frame programatically, whenever the dialog bar is docked and floated and docked back.
Thankx Very much
Dave
|
|
|
|
|
Before I get started, I should warn you that most development I have done has been in VB.
Now that the laughter has subsided, here is the problem:
I have the following:
IBaseData - An interface in a dll which will not contain any implementation code.
ISybaseData - An interface which I would like to inherit from IBaseData INSTEAD of IDispatch.
I get an error that says unresolved type declaration IBaseData in the SybaseData project. Does anyone know what I am doing wrong?
EDIT: The SybaseData dll has a static link (#import) to BaseData project. Is that wrong?
Note: When I have BOTH interfaces in the same project, and I hack around the .idl file it works fine and I get the desired effect. But when I try to inherit it from another project (dll) I get that error.
Goal: To be able to do have a client app have a static link to the BaseData dll. After I create the smart pointer, I can then load by Classname "SybaseData.MyData" onto the smart pointer because they export the same functions, but a different implementation. In the future, I would like to create a "OracleData.MyData" dll and so forth and so on. Am I going about this the wrong way? I would rather not do use Invoke because it is a pain to set up.
Please let me know if you need any clarification, as the entire post is probably a bit confusing 
|
|
|
|
|
If I am understanding your question correctly, you want to derive your new class from an existing interface. This interface exists in a separate DLL with a type library. Currently you are going to create one implementation of this interface, called SybaseData, inthe future you may create a different version of that interface called OracleData.
With that out of the way, either way that you are doing it is valid. If you use the #import statement in your IDL file, it will create the interface definitions automatically for you and make them available to the MIDL compiler.
Alternatively you could redeclare the IBaseData class yourself in your IDL file. As long as the guid matches and the interface is identical that method is valid as well.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Incredible. Thanks for the quick and informative reply, kilowatt.
The odd thing is that the #import IS indeed in my idl file and I still get "unresolved type declaration". The second method (which I didn't think of) should work, but I would really like the first method to work if possible.
Also, is this the "right" way to write a data abstraction layer? I would rather not have different rdbms code comingled in the same dll and unfortunately for this project, stored procedures aren't available.
EDIT: The #import is pointing to the BaseData.dll, if that helps.
Thanks in advance.
|
|
|
|
|
Does your BaseData.dll file have a typelibrary definition? That is the only way that the MIDL compiler will be able to extract the IDL definition for you new dll to use. A very easy way to tell is by referencing your BaseData.dll to a visual basic project. If VB finds the components or even interfaces inside of your dll, tehn it has a typelibrary.
If you do not have a type library inside of your BaseDLL then you will need to add the definition at the bottom of your IDL file for it.
One other way to do this is to import the IDL definition from your BaseDLL project if you used an IDL file originally.
If you want you can email me with more info.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
I am sorry, I have been leading you down the wrong path.
You cannot import a dll in the IDL file, you can only import IDL, ODL and header files. So that will be your best bet.
You can use the importlib() directive inside of your new type library, but the MSDN documentation recommends that you use the IDL file so that all of the items from the original file will be available to your app. If you rely on the data in teh DLL, you will only get what is in the type library (which this may also include all of the items in teh dll so it wouldn't matter).
Either way I think that using the IDL file from your base project is prefectly acceptable.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
