|
I would probably go Dialog, or Single document,
thought 1 : a tab bar, each tab being a section/TMATS header
thought 2 : 2 'panes' - left hand 'pane' is a tree structure (or listbox ?) of the file sections, when clicked upon, the TMATS header is displayed in detail on the right hand 'pane'
|
|
|
|
|
This is really helpful for me. I would not have thought of either one. If I google each will I find a good description?
I think the multiple tabs would be easier, but the split pane concept (kind of like Windows Explorer?) would also be cool. What is the approximate work effort for each? Maybe on a one to ten scale? I don't really care what the ten on that scale really means, just a comparison between the two. Maybe assign ten to the more difficult one and assign something less than ten to the easier one.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
just on a quick thought, the tabs are easier - caveat : as long as you only use them for 'displaying' data, ie, you dont have things going on in tabs that you need to pass between/to other tabs (Ive used a 5 tab bar as a workflow type thing, but an error in tab 3 meant they had to go back to tab 2 for example). One thing that may go against this is the size of the dialog, vs the number of tabs - 'fitting them on/scrolling them' so all the info is apparent to the user - with the dual pane view, you might not have that issue.
Im thinking '4' for tabs, and maybe '7' for split-pane
Again, if you have a class, with unit tests etc, that can handle parsing, 'getting sections', getting data from your TMATS files, then fitting it with a new UI shouldnt be a biggie
Im pretty sure google would bring up plenty of articles .. there's bound to be some lurking here on cp, if only for ideas
|
|
|
|
|
Thinking of Tabs: If I have a class in charge of writing, can it access the tabs to fetch the data, then write the data to a new file?
I presume I would need to create some type of writer class that would be able to poll each tab asking for the data contained within the tab. (Presuming each tab is a separate object ) to provide the data to the file writer. Then the file writer class would poll each tab to get the data to write out.
Its past my bedtime so I'll not respond again and catch up tomorrow. But again, this has been very helpful for me. Thank you for taking the time to maintain this conversation.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
I forgot about this [requirement]
>> The user will be able to edit the data and write out to a new file.
So maybe the tabs have some sort of edit - possibly hex edit control on them
Its not impossible - a 'commit changes' or 'write to file' button on the main dialog would loop through the tabs writing the data obtained from the edit control on it.
I think I would write, from an abstraction point of view ...
3. GUI Code
2. Tab Manager - Possibly linked to buffer manager/dirty flag - you need to know the order of the tabs and if they have been changed or not
1. File Parser/Writer
its about bed time for me too 
|
|
|
|
|
Hi all!
I want to do it, same as my topic...
do pratical???
if this can, and can u help me.
thanks so much
|
|
|
|
|
Hi guys,
I'm confused. I need to create interprocess communications between x64 and x86 processes running on the same machine.
Can I use COM for it? Cannot see anything on web.
Or does that mean that I must use DCOM?
Thanks for help.
|
|
|
|
|
Both COM and DCOM are dangerous to use and can easily crash both processes if there is a bug.
IMHO it is better when you use sockets for the inter-process communications because it makes the way your communication works more reliable and the two processes gain a bit of independence (of course you have to add error handling for failed communication attempts, otherwise you are having the same problem as with DCOM and COM).
Just my two cents about how we use to do it at our company.
|
|
|
|
|
I will take into account your 2 cents  . Still, the question is open.
|
|
|
|
|
Off course there are opportunities when you need to use COM or DCOM, but the savest way of using them is to avoid the usage  .
|
|
|
|
|
I've only used DCOM between machines and processes. When I did try to use it quite a while ago, I soon gave up on it due to security and permission problems when trying to do anything between machines in a corporate environment and so used MSMQ (Message Queuing) instead - much easier to work with and provides nice decoupling. Setup a named queue, connect at one end to post messages, connect at the other end to receive messages. Makes testing easy too. As others have said there are other ways as well.
|
|
|
|
|
I would definitely use a socket for IPC, maybe shared memory in some cases. The most lightweight interprocess communication channel is probably an unnamed pipe but sockets are more flexible not to mention that the loopback interface is decoupled from the network stack so if both endpoints are on your machine then sockets are super-fast. With sockets you have the opportunity to run the processes on different machines anytime without much effort (possible with name pipes too, but thats more hassle and not crossplatform like sockets). In my opinion COM and DCOM are just unnecessary complications to solve your problem.
|
|
|
|
|
I backup the opinions on using sockets. Use them. That knowledge will help in the long run and will be good for other platforms. I wrote some articles on TCP/IP that might be useful. Search for them on this site.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
You can use COM objects if you make sure they are automation compatible (have the [oleautomation] attribute and use only automation compatible types in their methods). This will assure that all required marshalling code exists - it will be just like DCOM. There might be other ways (like writing your own marshalling code), but this is a way that will work. You can, of course, also use DCOM.
However, it depends very much on the details of your project, is this is the right way. The advantages are, that COM takes care of everything, like marshalling your data correctly (even between 32/64 bit processes). But also you might run into a lot of things that will be not so easy to solve for unexperienced COM programmers.
There are quite some articles here on CP about IPC, might be worth to take a look there.
In case you want to experiment a bit (and I would strongly suggest that before you decide for a certain solution!) I would suggest WTL (check out http://www.codeproject.com/kb/wtl/ [^]. A series of some very good articles is Michael Dunn's WTL for MFC Programmers). Create a project with the option "Create as COM Server" (will appear in the Application wizard). It will give you an exe project with a UI, that also acts as a COM server. Create two such projects in your solution, add some COM objects and start to play around a bit.
|
|
|
|
|
Normally the backward compatibility was planed to ensure that if one soft is compiled for an old version of the library, it can continue to work with the new higher version of the library without recompilation or special adaptation.(situation 1)
Is the reverse also true?
Means if the soft is compiled with the new higher version of dll it can continue to work with the old version of the library without recompilation or special adaptation.(situation 2)
My situation is the first one, So I ask if should I have also situation 2 works ?
|
|
|
|
|
Without knowing what library you are talking about, or what your program does, it is impossible to answer this question.
Use the best guess
|
|
|
|
|
In the end, no one of us can see into the future, therefore it is not possible to say that your program will work with another version of the DLL in the future. Just because it is... you know... the future.
|
|
|
|
|
I had an application which is using MFC serialization mechanism w.r.t MBCS (both for serialization/ de serialization ). Now I would like to convert my application to read/write Unicode using MFC serialization mechanism.
What would list of changes in this regard. (dos & dont's) Thanks in Advance !!
|
|
|
|
|
Apart from the fact that you need to use the WCHAR and PWSTR types to refer to your characters there is no difference.
Use the best guess
|
|
|
|
|
My code is:
class CSubTapiCom;
class CWinHidden :
public CWindowImpl
{
BEGIN_MSG_MAP(CWinHidden)
MESSAGE_HANDLER(WM_COPYDATA, OnCopyData)
MESSAGE_HANDLER(WM_TIMER, OnTimer)
END_MSG_MAP()
public:
//CWinHidden() {};
CWinHidden(CSubTapiCom* pFullCtrl) : m_pFullCtrl(pFullCtrl) {};
public:
LRESULT OnCopyData(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
LRESULT CWinHidden::OnCopyData(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
m_pFullCtrl->OnCopyData(uMsg, wParam, lParam, bHandled);
return 0;
}
private:
CSubTapiCom* m_pFullCtrl;
};
// CSubTapiCom
class ATL_NO_VTABLE CSubTapiCom :
public CComObjectRootEx,
public CStockPropImpl,
public IPersistStreamInitImpl,
public IOleControlImpl,
public IOleObjectImpl,
public IOleInPlaceActiveObjectImpl,
public IViewObjectExImpl,
public IOleInPlaceObjectWindowlessImpl,
public ISupportErrorInfo,
public IConnectionPointContainerImpl,
public CProxy_ISubTapiComEvents,
public IPersistStorageImpl,
public ISpecifyPropertyPagesImpl,
public IQuickActivateImpl,
#ifndef _WIN32_WCE
public IDataObjectImpl,
#endif
public IProvideClassInfo2Impl<&CLSID_SubTapiCom, &__uuidof(_ISubTapiComEvents), &LIBID_SubTapiATLcomLib>,
#ifdef _WIN32_WCE // IObjectSafety is required on Windows CE for the control to be loaded correctly
public IObjectSafetyImpl,
#endif
public CComCoClass,
public CComControl
{
CWinHidden m_wndHidden;
HWND m_hHidden;
UINT m_uintTimer;
public:
CSubTapiCom() : m_wndHidden(this)
{
}
DECLARE_OLEMISC_STATUS(OLEMISC_RECOMPOSEONRESIZE |
OLEMISC_CANTLINKINSIDE |
OLEMISC_INSIDEOUT |
OLEMISC_ACTIVATEWHENVISIBLE |
OLEMISC_SETCLIENTSITEFIRST
)
DECLARE_REGISTRY_RESOURCEID(IDR_SUBTAPICOM)
BEGIN_COM_MAP(CSubTapiCom)
COM_INTERFACE_ENTRY(ISubTapiCom)
COM_INTERFACE_ENTRY(IDispatch)
COM_INTERFACE_ENTRY(IViewObjectEx)
COM_INTERFACE_ENTRY(IViewObject2)
COM_INTERFACE_ENTRY(IViewObject)
COM_INTERFACE_ENTRY(IOleInPlaceObjectWindowless)
COM_INTERFACE_ENTRY(IOleInPlaceObject)
COM_INTERFACE_ENTRY2(IOleWindow, IOleInPlaceObjectWindowless)
COM_INTERFACE_ENTRY(IOleInPlaceActiveObject)
COM_INTERFACE_ENTRY(IOleControl)
COM_INTERFACE_ENTRY(IOleObject)
COM_INTERFACE_ENTRY(IPersistStreamInit)
COM_INTERFACE_ENTRY2(IPersist, IPersistStreamInit)
COM_INTERFACE_ENTRY(ISupportErrorInfo)
COM_INTERFACE_ENTRY(IConnectionPointContainer)
COM_INTERFACE_ENTRY(ISpecifyPropertyPages)
COM_INTERFACE_ENTRY(IQuickActivate)
COM_INTERFACE_ENTRY(IPersistStorage)
#ifndef _WIN32_WCE
COM_INTERFACE_ENTRY(IDataObject)
#endif
COM_INTERFACE_ENTRY(IProvideClassInfo)
COM_INTERFACE_ENTRY(IProvideClassInfo2)
#ifdef _WIN32_WCE // IObjectSafety is required on Windows CE for the control to be loaded correctly
COM_INTERFACE_ENTRY_IID(IID_IObjectSafety, IObjectSafety)
#endif
END_COM_MAP()
BEGIN_PROP_MAP(CSubTapiCom)
PROP_DATA_ENTRY("_cx", m_sizeExtent.cx, VT_UI4)
PROP_DATA_ENTRY("_cy", m_sizeExtent.cy, VT_UI4)
PROP_ENTRY_TYPE("AutoSize", DISPID_AUTOSIZE, CLSID_NULL, VT_BOOL)
// Example entries
// PROP_ENTRY_TYPE("Property Name", dispid, clsid, vtType)
// PROP_PAGE(CLSID_StockColorPage)
END_PROP_MAP()
BEGIN_CONNECTION_POINT_MAP(CSubTapiCom)
CONNECTION_POINT_ENTRY(__uuidof(_ISubTapiComEvents))
END_CONNECTION_POINT_MAP()
BEGIN_MSG_MAP(CSubTapiCom)
CHAIN_MSG_MAP(CComControl)
DEFAULT_REFLECTION_HANDLER()
MESSAGE_HANDLER(WM_COPYDATA, OnCopyData)
END_MSG_MAP()
// ISupportsErrorInfo
STDMETHOD(InterfaceSupportsErrorInfo)(REFIID riid)
{
static const IID* arr[] =
{
&IID_ISubTapiCom,
};
for (int i=0; im_hWnd;
this->m_hWndCD;
RECT rect;
CString cstrName("subtapirec");
m_hHidden = m_wndHidden.Create(NULL, rect,cstrName);
return S_OK;
}
void FinalRelease()
{
::KillTimer(m_hHidden, 1);
m_wndHidden.DestroyWindow();
}
LRESULT OnCopyData(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
::MessageBox(NULL, _T("OnCopyData...1"), _T("INFO"), MB_OK);
return 0;
}
};
|
|
|
|
|
1. Please enclose your code in <pre> tags so it looks clear, as:
LRESULT OnCopyData(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
::MessageBox(NULL, _T("OnCopyData...1"), _T("INFO"), MB_OK);
return 0;
}
2. Please explain what your problem is.
Use the best guess
|
|
|
|
|
Hi All
I have this call to CoCreateInstance that fails, and i get 0x0000007e from GetLastError. Has everybody allready had this kind of error ?
Thank you.
// import VoipTestCom.dll
#pragma warning(disable:4146)
#import "C:\workvs2008\binaries\Win32\Release\bin\VoipTestCom.dll" raw_interfaces_only, raw_native_types, no_namespace, named_guids
LRESULT CSTapiCom::OnInitDialog(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
ISimpleClientPtr m_sipclicom;
CAxWindow wnd;
CLSID clsid;
LPUNKNOWN pUnkCtrl, pUnkCont;
HRESULT hr = CLSIDFromProgID(OLESTR("VoipTestCom.SimpleClient"), &clsid);
if (hr == S_OK )
{
::MessageBox(NULL, _T("CLSIDFromProgID...ok"), _T("INFO"), MB_OK);
}
hr = CoCreateInstance(clsid, NULL, CLSCTX_ALL, IID_IUnknown, (void**)&pUnkCtrl);
if (hr == S_OK )
{
::MessageBox(NULL, _T("CoCreateInstance...ok"), _T("INFO"), MB_OK);
}
else
{
TCHAR szBuff[64];
swprintf(szBuff, L"CoCreateInstance...fail->%x",GetLastError());
::MessageBox(NULL, szBuff, _T("INFO"), MB_OK);
}
return TRUE;
}
|
|
|
|
|
What was the status returned from the call to CoCreateInstance?
Use the best guess
|
|
|
|
|
i get 0x0000007e from GetLastError
|
|
|
|
|
According to the documentation[^] that is equivalent to ERROR_MOD_NOT_FOUND which means it cannot find the file containing the COM class.
Use the best guess
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
